Hi all
I'm wrestling my way through OOPs concepts and have a question on set{}. Can
anyone help
From the stuff I've been reading, set and get are accessors to class
properties (i.e. local class variables) which inturn are used to reflect the
state of a particular object.
I can understand using get{} to allow other classes to see the state of an
object, but when would you use set{} to change the state/local data?
In my mind (poor as it is) , I can only imagine the state of an object ever
being changed within the class i.e. An external class executes a method and
the method may or may not adjust the state of the class, depending on the
result of the action.
so I suppose in summary I'm asking why would you use set{} rather than use a
method (other than you don't have to use parenthesis when calling)?
many thanks if anyone can clear up my misunderstanding
thanks
Andy 8 996
It is all about properties definition...
- set and get are also methods, so it doesn't matter whether you call a
method of the class that sets the local var, or whether you are assigning
value to the property.
- it all depends on design: if you set the value of class var with a method
you have the possibility to pass additional parameters along with the value
to set.
- if digging the the OOP basics we have the definition that properties
reflect the state of the object and methods perform something with the
object. So if you have Car object it is better to say carObj.Color = "red"
( set{} ) to set the attribute of a car and if you want to have the action
arObj.RideWithSpeed(100)
--
Vadym Stetsyak aka Vadmyst
"aaj" <aa*@aaj.com> wrote in message
news:1121936085.7811103a6d0bf5a749c0d500e01c66c9@t eranews... Hi all
I'm wrestling my way through OOPs concepts and have a question on set{}.
Can anyone help
From the stuff I've been reading, set and get are accessors to class properties (i.e. local class variables) which inturn are used to reflect
the state of a particular object.
I can understand using get{} to allow other classes to see the state of an object, but when would you use set{} to change the state/local data?
In my mind (poor as it is) , I can only imagine the state of an object
ever being changed within the class i.e. An external class executes a method
and the method may or may not adjust the state of the class, depending on the result of the action.
so I suppose in summary I'm asking why would you use set{} rather than use
a method (other than you don't have to use parenthesis when calling)?
many thanks if anyone can clear up my misunderstanding
thanks
Andy
aaj <aa*@aaj.com> wrote: I'm wrestling my way through OOPs concepts and have a question on set{}. Can anyone help
From the stuff I've been reading, set and get are accessors to class properties (i.e. local class variables) which inturn are used to reflect the state of a particular object.
I can understand using get{} to allow other classes to see the state of an object, but when would you use set{} to change the state/local data?
In my mind (poor as it is) , I can only imagine the state of an object ever being changed within the class i.e. An external class executes a method and the method may or may not adjust the state of the class, depending on the result of the action.
so I suppose in summary I'm asking why would you use set{} rather than use a method (other than you don't have to use parenthesis when calling)?
Precisely for the last reason - it's simpler to read
foo.SomeProperty = bar.SomeOtherProperty;
than
foo.setSomeProperty(bar.getSomeOtherProperty());
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Your question, I think, looks at things from a different angle than
Microsoft did.
Properties are a response to the "old" O-O model of "fields and
methods": in this model, the programmer had only two choices: make
fields public and mess with them directly, or write methods for getting
and setting field values. Java later instituted the JavaBean pattern,
which insisted that every publicly accessible field had to have a "get"
method, and maybe a "set" method, too.
Many programmers preferred to sidestep writing "get-set" all over the
place and just made some fields public, which is very bad style.
C# responded to the "public field" problem by introducing properties,
which from the outside look just like fields, but add the opportunity
to introduce code between the private field and the client. The
reasoning? If you hide your public fields behind properties, you can
later add logic to the setter (and maybe the getter too) without
changing client code at all.
Properties do not at all go against the OOP basics you talk about.
Property setters can have code in them because sometimes setting a
property value, like carObj.Color = "red", implies that other things
must change as well in order to maintain internal consistency in the
object state. This is the kind of code that should go in a setter: code
that is conceptually irrelevant to the client. The client still sees
the property as a simple attribute of the class, not as something done
to the class. It's all about levels of abstraction: the conceptual
level of the public face of the class versus what has to go on inside
it in order to maintain that public abstraction.
So, now you're looking at it from the other angle: properties entrench
the design decision that the setter will never need arguments, so why
not just always use get() and set() methods. As Jon pointed out, the
syntax of properties is certainly simpler, but on top of that I claim
that using get() and set() doesn't really buy you anything. Let's look
at change under the two scenarios.
First, let's say you've published your DLL with a property called Color
that takes a System.Drawing.Color object. Later on, you discover that
your property can't be a property: that in fact you need additional
information in order to set the Color, so you need to make a
SetColor(...) method. Now you have to re-publish your DLL with a major
change that will force any client that uses the Color property to
modify their code and recompile. Yuck.
Second, let's say you've published your DLL with a method called
SetColor() that takes a System.Drawing.Color object as its only
parameter. Later on, you discover that your method needs a second
argument. Now you have to re-publish your DLL with a major change that
will force any client that calls the original SetColor() to modify
their code and recompile.
So where's the difference? I don't see any. Either way, you have to
break your clients' code: they have to change code and recompile
because you've made an incompatible change to the calling contract.
A change is a change is a change. Whether you change a property to a
method, or you change a method to have another parameter, it's the same
pain. Plus, properties, as Jon pointed out, are easier to code and
easier to read, so properties win. :)
Your question, I think, looks at things from a different angle than
Microsoft did.
Properties are a response to the "old" O-O model of "fields and
methods": in this model, the programmer had only two choices: make
fields public and mess with them directly, or write methods for getting
and setting field values. Java later instituted the JavaBean pattern,
which insisted that every publicly accessible field had to have a "get"
method, and maybe a "set" method, too.
Many programmers preferred to sidestep writing "get-set" all over the
place and just made some fields public, which is very bad style.
C# responded to the "public field" problem by introducing properties,
which from the outside look just like fields, but add the opportunity
to introduce code between the private field and the client. The
reasoning? If you hide your public fields behind properties, you can
later add logic to the setter (and maybe the getter too) without
changing client code at all.
Properties do not at all go against the OOP basics you talk about.
Property setters can have code in them because sometimes setting a
property value, like carObj.Color = "red", implies that other things
must change as well in order to maintain internal consistency in the
object state. This is the kind of code that should go in a setter: code
that is conceptually irrelevant to the client. The client still sees
the property as a simple attribute of the class, not as something done
to the class. It's all about levels of abstraction: the conceptual
level of the public face of the class versus what has to go on inside
it in order to maintain that public abstraction.
So, now you're looking at it from the other angle: properties entrench
the design decision that the setter will never need arguments, so why
not just always use get() and set() methods. As Jon pointed out, the
syntax of properties is certainly simpler, but on top of that I claim
that using get() and set() doesn't really buy you anything. Let's look
at change under the two scenarios.
First, let's say you've published your DLL with a property called Color
that takes a System.Drawing.Color object. Later on, you discover that
your property can't be a property: that in fact you need additional
information in order to set the Color, so you need to make a
SetColor(...) method. Now you have to re-publish your DLL with a major
change that will force any client that uses the Color property to
modify their code and recompile. Yuck.
Second, let's say you've published your DLL with a method called
SetColor() that takes a System.Drawing.Color object as its only
parameter. Later on, you discover that your method needs a second
argument. Now you have to re-publish your DLL with a major change that
will force any client that calls the original SetColor() to modify
their code and recompile.
So where's the difference? I don't see any. Either way, you have to
break your clients' code: they have to change code and recompile
because you've made an incompatible change to the calling contract.
A change is a change is a change. Whether you change a property to a
method, or you change a method to have another parameter, it's the same
pain. Plus, properties, as Jon pointed out, are easier to code and
easier to read, so properties win. :)
Thanks for the considered responses guys..
I'll take some time to digest, (in particular Bruces 8-) )
One example is the car colour used as a property. In my mind changing the
car colour is still an action (or a verb string setCarColour), and I would
expect some code in a method to see if first of all the colour existed, and
then, if it did, to set the property CarColour to red (but I suppose you can
perform the same checks with a set{}).
I have to admit , I'm still missing the sublety of the difference although
the readability statement makes a lot of sense.
I'll have another read through and give Bruces some more thoughts.
thanks again
Andy
P.s.
I've gone from finding this OOP's stuff very difficult to comprehend to
almost comprehending, Its been a long, long tunnel though!!!
"aaj" <aa*@aaj.com> wrote in message
news:1121936085.7811103a6d0bf5a749c0d500e01c66c9@t eranews... Hi all
I'm wrestling my way through OOPs concepts and have a question on set{}. Can anyone help
From the stuff I've been reading, set and get are accessors to class properties (i.e. local class variables) which inturn are used to reflect the state of a particular object.
I can understand using get{} to allow other classes to see the state of an object, but when would you use set{} to change the state/local data?
In my mind (poor as it is) , I can only imagine the state of an object ever being changed within the class i.e. An external class executes a method and the method may or may not adjust the state of the class, depending on the result of the action.
so I suppose in summary I'm asking why would you use set{} rather than use a method (other than you don't have to use parenthesis when calling)?
many thanks if anyone can clear up my misunderstanding
thanks
Andy
Thanks for the considered responses guys..
I'll take some time to digest, (in particular Bruces 8-) )
One example is the car colour used as a property. In my mind changing the
car colour is still an action (or a verb string setCarColour), and I would
expect some code in a method to see if first of all the colour existed, and
then, if it did, to set the property CarColour to red (but I suppose you can
perform the same checks with a set{}).
I have to admit , I'm still missing the sublety of the difference although
the readability statement makes a lot of sense.
I'll have another read through and give Bruces some more thoughts.
thanks again
Andy
P.s.
I've gone from finding this OOP's stuff very difficult to comprehend to
almost comprehending, Its been a long, long tunnel though!!!
"aaj" <aa*@aaj.com> wrote in message
news:1121936085.7811103a6d0bf5a749c0d500e01c66c9@t eranews... Hi all
I'm wrestling my way through OOPs concepts and have a question on set{}. Can anyone help
From the stuff I've been reading, set and get are accessors to class properties (i.e. local class variables) which inturn are used to reflect the state of a particular object.
I can understand using get{} to allow other classes to see the state of an object, but when would you use set{} to change the state/local data?
In my mind (poor as it is) , I can only imagine the state of an object ever being changed within the class i.e. An external class executes a method and the method may or may not adjust the state of the class, depending on the result of the action.
so I suppose in summary I'm asking why would you use set{} rather than use a method (other than you don't have to use parenthesis when calling)?
many thanks if anyone can clear up my misunderstanding
thanks
Andy
Think about a Control/Component. The Button.Text property is a good
example. When you set the Text property, you need to tell the control to
redraw itself so it shows the new text. You may also want to do validation
on the data, which can be done in the set accessor.
--
Floyd
"aaj" <aa*@aaj.com> wrote in message
news:1121936085.7811103a6d0bf5a749c0d500e01c66c9@t eranews... Hi all
I'm wrestling my way through OOPs concepts and have a question on set{}. Can anyone help
From the stuff I've been reading, set and get are accessors to class properties (i.e. local class variables) which inturn are used to reflect the state of a particular object.
I can understand using get{} to allow other classes to see the state of an object, but when would you use set{} to change the state/local data?
In my mind (poor as it is) , I can only imagine the state of an object ever being changed within the class i.e. An external class executes a method and the method may or may not adjust the state of the class, depending on the result of the action.
so I suppose in summary I'm asking why would you use set{} rather than use a method (other than you don't have to use parenthesis when calling)?
many thanks if anyone can clear up my misunderstanding
thanks
Andy
Think about a Control/Component. The Button.Text property is a good
example. When you set the Text property, you need to tell the control to
redraw itself so it shows the new text. You may also want to do validation
on the data, which can be done in the set accessor.
--
Floyd
"aaj" <aa*@aaj.com> wrote in message
news:1121936085.7811103a6d0bf5a749c0d500e01c66c9@t eranews... Hi all
I'm wrestling my way through OOPs concepts and have a question on set{}. Can anyone help
From the stuff I've been reading, set and get are accessors to class properties (i.e. local class variables) which inturn are used to reflect the state of a particular object.
I can understand using get{} to allow other classes to see the state of an object, but when would you use set{} to change the state/local data?
In my mind (poor as it is) , I can only imagine the state of an object ever being changed within the class i.e. An external class executes a method and the method may or may not adjust the state of the class, depending on the result of the action.
so I suppose in summary I'm asking why would you use set{} rather than use a method (other than you don't have to use parenthesis when calling)?
many thanks if anyone can clear up my misunderstanding
thanks
Andy This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Michael Klatt |
last post by:
I am trying to write an iterator for a std::set that allows the
iterator target to be modified. Here is some relvant code:
template <class Set> // Set is an instance of std::set<>
class...
|
by: William Payne |
last post by:
Hello, I have a variable of type unsigned long. It has a number of bits set
(with set I mean they equal one). I need to determine those bits and their
position and create new numbers from them. For...
|
by: snnn |
last post by:
On the book <Generic Programming and the STL>( Matthew . H . Austern ),this function is defined as
iterator set::begin() const.
However, why should a const object returns a non-const iterator?...
|
by: uclamathguy |
last post by:
I am working on connected component analysis, but that is irrelevant. I
have a mapping containing ints as the keys and sets of ints as the
"values."
Given an integer, I need to iterate through...
|
by: Prawit Chaivong |
last post by:
Hi, gurus
Is it safe to do this in function?
'return &(*iterator)';
And iterator is std::set<something>::iterator
Regards,
|
by: teddysnips |
last post by:
I am trying to insert a row into a table using a stored procedure and I
get the following error if I try this from QA:
INSERT failed because the following SET options have incorrect
settings:...
|
by: Yuri CHUANG |
last post by:
This is a example from a textbook,but there are some strange error that
I don't understand.Could anyone give me some help to realize the
operations on set.Thank you very much:-)
(I compile it with...
|
by: bearophileHUGS |
last post by:
>From this interesting blog entry by Lawrence Oluyede:
http://www.oluyede.org/blog/2006/07/05/europython-day-2/
and the Py3.0 PEPs, I think the people working on Py3.0 are doing a
good job, I am...
|
by: kuangye |
last post by:
Hi, all.
Is there any library supporting set operation such as union,
intersection, difference on sets of integer numbers.
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: ArrayDB |
last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
by: Shællîpôpï 09 |
last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
| |