Whet to Use set{}

  • Thread starter Thread starter aaj
  • Start date Start date
A

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
 
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)
 
aaj said:
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)?
Click to expand...

Precisely for the last reason - it's simpler to read

foo.SomeProperty = bar.SomeOtherProperty;

than

foo.setSomeProperty(bar.getSomeOtherProperty());
 
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!!!
 
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.
 
Back
Top