473,326 Members | 2,104 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Whet to Use set{}

aaj
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
Nov 17 '05 #1
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

Nov 17 '05 #2
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
Nov 17 '05 #3
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. :)

Nov 17 '05 #4
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. :)

Nov 17 '05 #5
aaj
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

Nov 17 '05 #6
aaj
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

Nov 17 '05 #7
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

Nov 17 '05 #8
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

Nov 17 '05 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

26
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...
7
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...
11
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?...
3
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...
7
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,
4
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:...
4
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...
22
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...
3
by: kuangye | last post by:
Hi, all. Is there any library supporting set operation such as union, intersection, difference on sets of integer numbers.
0
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...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
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...
1
isladogs
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...
0
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...
0
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...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
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....
0
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

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.