Why are get/set properties useful?

[VMI]

WHy are the get/set properties so useful? I know they're used so that I don't
directly access a variable, but why is that so useful? What would the
difference be between using it directly and using get/set?

Thanks.

[Clint]

By using the properties, as opposed to making the variables they access
public, you can control what data goes into them, and how the data is
returned. For example, on the set property, you can validate the data and
return an error if it isn't valid. So if you have a State property on an
address object, you can make sure that it's one of 51 valid entries. Or you
can make sure a string will fit into a database field before you allow it to
be stuck into the field, so you always know the object is valid.

I haven't found as much use for the get property, but you can use it for the
same sort of things. You can also use JUST a get property to make a
read-only property (so once the object is loaded with data from the
contructor or a "fill" function, external applications and objects can only
read the values).

Anyway, there you go. My $0.02.

Clint

"VMI" <VM*@discussions.microsoft.com> wrote in message
news:4C**********************************@microsof t.com...

WHy are the get/set properties so useful? I know they're used so that I
don't
directly access a variable, but why is that so useful? What would the
difference be between using it directly and using get/set?

Thanks.

[Matt]

VMI wrote:

WHy are the get/set properties so useful? I know they're used so that I don't
directly access a variable, but why is that so useful? What would the
difference be between using it directly and using get/set?

Thanks.

Lots of reasons, but the biggest one is control and conversion.

Control:
Let's assume that for some reason, my value can only be from 1-10.
If I allow the user to assign a value outside that range, my program
may
crash or do weird things. If the setter does not allow a value outside
the
range 1-10, I don't have this problem. Likewise, let's say that I want
to
change some OTHER variable when you set one of the values. I can do
that in the setter. Finally, suppose that I don't want to do things if
the
value you give me is the same as the current value. I can do that in a
setter.

Conversion:
If I have a set routine that takes a value of another type, such as a
string
instead of an integer, I can convert it to whatever I want without the
user
being aware of what my internal representation is.

Matt

[Marc Gravell]

Smells of homework, but...

Starters for 10:

* In the accessors (get/set) you might want to apply locking to prevent 2
threads monkeying with the value at once
* In the accessors you might want to validate the new value; check it is
legal and throw an exception if not (and yes: exceptions from setters IS
reasonable; the framework does it often enough; sometimes the getter might
throw if it is not reasonable to ask this)
* The setter (or more rarely, getter) may have local consequences beyond the
constraints of that field; arguably should be exposed via a method, but does
happen
* The setter might want to notify other code that a change has occurred via
notification events
* The value might be lazy-loaded, so not known until queried (e.g. still in
the db)
* The value might be dynamically calculated (think .Count)
* Isolates implementation from interface
* Might want different access; read only (.Count), write only (.Password),
or different access on the getter and setter (possible in 2.0)
* For value-types, the difference is more pronounced; a getter will return a
*clone* of the value; hence .SomeStructProperty.SomeMethod() and
..SomeStructField.SomeMethod() are very different; the property one works on
a different object, the field works on the same

Marc

[VMI]

Thanks for the info. And it's not for homework LOL It's just that I've seen
it alot and just didn't fully understand it.
I had a vague idea that it might be for data control, but all the examples
I've seen didn't make much sense. In this example (comes from a tutorial)
it's being used without much purpose:

class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

"VMI" wrote:

WHy are the get/set properties so useful? I know they're used so that I don't
directly access a variable, but why is that so useful? What would the
difference be between using it directly and using get/set?

Thanks.

[Bob Powell [MVP]]

A fundamental principle of object orientation is encapsulation.

An object should have full control over it's data at all times.

The get-set accessor enables an object to ensure that it must do some
intelligent processing when an external object tries to update it's data.

Exposing public variables is a huge no-no because an external object can
change the state of the variable without the owning obects knowledge. This
is a recipie for disaster.

There is no good excuse for public variables in a well designed
object-oriented architecture.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"VMI" <VM*@discussions.microsoft.com> wrote in message
news:4C**********************************@microsof t.com...

WHy are the get/set properties so useful? I know they're used so that I
don't
directly access a variable, but why is that so useful? What would the
difference be between using it directly and using get/set?

Thanks.

[Kevin Spencer]

> I haven't found as much use for the get property, but you can use it for

the same sort of things. You can also use JUST a get property to make a
read-only property (so once the object is loaded with data from the
contructor or a "fill" function, external applications and objects can
only read the values).
Here's one. In the following example, class a contains an instance of class
b, but doesn't want to expose all of it to the client. So, it uses public
properties to expose those properties of b as it wants to:

public class a
{
private class b;

public int c
{
get { return b.c; }
}

public a()
{ b = new b(); }
}

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

"Clint" <no****@nowhere.non> wrote in message
news:uu**************@TK2MSFTNGP03.phx.gbl... By using the properties, as opposed to making the variables they access
public, you can control what data goes into them, and how the data is
returned. For example, on the set property, you can validate the data and
return an error if it isn't valid. So if you have a State property on an
address object, you can make sure that it's one of 51 valid entries. Or
you can make sure a string will fit into a database field before you allow
it to be stuck into the field, so you always know the object is valid.

I haven't found as much use for the get property, but you can use it for
the same sort of things. You can also use JUST a get property to make a
read-only property (so once the object is loaded with data from the
contructor or a "fill" function, external applications and objects can
only read the values).

Anyway, there you go. My $0.02.

Clint

"VMI" <VM*@discussions.microsoft.com> wrote in message
news:4C**********************************@microsof t.com...

WHy are the get/set properties so useful? I know they're used so that I
don't
directly access a variable, but why is that so useful? What would the
difference be between using it directly and using get/set?

Thanks.

[JaredHite1]

"There is no good excuse for public variables in a well designed
object-oriented architecture."
That's a fairly bold statement...Particularly when you can't send a
property by reference to a function. In an SAP application I
maintained, I saw a class that contained public variables so they could
be passed byref to the SAP connector and be filled/instantiated by its
code. I know it could have been done in another way, but I thought
using public fields was at least not completely insane in this
instance.

-Jared

[Kevin Spencer]

Like any other rules, this sort of rule is based upon the underlying
principle. It is better to understand the underlying principle than to
simply adhere to a set of rules. The rules will, as you've observed, have
exceptions, while the underlying principles have none. In addition, it is an
easy trap to get caught up in the complexity and sheer number of rules which
may be derived from a principle, which, due to the number of rules,
exceptions and special cases, are much harder to keep track of than basic
underlying, unchanging principles.

When someone tells you a rule, it is often a good idea to ask them to
explain the underlying principle behind it. If they cannot, the rule is more
likely to be unreliable.

Note that I am not saying that the rule in question is not generally true.
It is. I am merely making a point in principle about the usefulness of
relying upon rules rather than principles.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

"JaredHite1" <ja***@sharingds.org> wrote in message
news:11**********************@e56g2000cwe.googlegr oups.com...

"There is no good excuse for public variables in a well designed
object-oriented architecture."
That's a fairly bold statement...Particularly when you can't send a
property by reference to a function. In an SAP application I
maintained, I saw a class that contained public variables so they could
be passed byref to the SAP connector and be filled/instantiated by its
code. I know it could have been done in another way, but I thought
using public fields was at least not completely insane in this
instance.

-Jared

[rmacias]

Here's one that might make more sense. It's just a simple example:

public class Circle
{
private float centerPoint;
private float radius;

public float Diameter
{
get { return radius * 2.0; }
}

public float Circumference
{
get { return 2.0 * Math.Pi * radius; }
}

public void Draw Circle()
{
//Draw circle to some object
}

public float Radius
{
get { return radius; }
set {
if( value > 0.0)
{
radius = value;
DrawCircle();
}
else
{
throw new Exception ("Invalid radius.");
}
}
}

"VMI" wrote:

Thanks for the info. And it's not for homework LOL It's just that I've seen
it alot and just didn't fully understand it.
I had a vague idea that it might be for data control, but all the examples
I've seen didn't make much sense. In this example (comes from a tutorial)
it's being used without much purpose:

class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

"VMI" wrote:

WHy are the get/set properties so useful? I know they're used so that I don't
directly access a variable, but why is that so useful? What would the
difference be between using it directly and using get/set?

Thanks.

[Martijn Mulder]

Properties are translated to functions (methods) by the compiler. The
properties below turn into

public int get_X(){return x;}
public void set_X(int value){x=value;}

but you access X as if it is a data member, not a method. The compiler turns
a property into a function.

I find properties one of the best things in C#. They are really cool.

class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

WHy are the get/set properties so useful? I know they're used so that I
don't
directly access a variable, but why is that so useful? What would the
difference be between using it directly and using get/set?

[Bob Powell [MVP]]

Hi Jared,

I think that the statement is only as bold as it needs to be. An
understanding of oo principles dictates that the object must be in control
of it's data at all times otherwise we need to resort to horrible global
variables and the resulting spaghetti code. You can write bad code with .NET
it's true but it's a choice that the developer makes, not a shortcoming of
the language. You'll forgive me for saying so but VB developers do this more
than usual because the mind-set of the language has been migrated too darn
late from the world of flat code and global variables.

The example you cite seems like the epitome of poor excuses to me. If a
property contains ref objects the reference is passed under the covers. It
would be ridiculous to pass a 300 megabyte image any other way would it not?
If the property contains a simple value type then the developer should know
this and specify reference passing should the architecture require it.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"JaredHite1" <ja***@sharingds.org> wrote in message
news:11**********************@e56g2000cwe.googlegr oups.com...

"There is no good excuse for public variables in a well designed
object-oriented architecture."
That's a fairly bold statement...Particularly when you can't send a
property by reference to a function. In an SAP application I
maintained, I saw a class that contained public variables so they could
be passed byref to the SAP connector and be filled/instantiated by its
code. I know it could have been done in another way, but I thought
using public fields was at least not completely insane in this
instance.

-Jared

[JaredHite1]

Hi Bob-
My mother warned me not to disagree with MVPs...I should have listened
:-) But I'm not sure you understood my example...I'm not talking about
passing reference objects to functions, but passing by reference
explicitly using the ref keyword, which results in a compile-time error
when you try to do it with properties. Maybe It will be more clear if
I illustrate it:

//Code in an assembly far outside of my control:
public void RunGetOrderBAPI(string order number,
ref PricingConditionTable,
ref ScheduleLineTable,
ref HeaderStructure,
ref LineItems,
Functions like this to get tables and structures may have 50
parameters, each of which is a fairly hefty object that is passed by
ref
) {}

//Code under my control
internal class GetOrderBapiData
{
public PricingConditionTable = new PricingTable();
public ScheduleLineTable = new ScheduleLineTable();
public HeaderStructure = new HeaderStructure();
public LineItemTable = new LineItemTable();
....50 or so more public fields, corresponding to the parameters we'll
need to send into RunGetOrderBAPI
}

//in some data access class
public GetOrderBapiData GetOrder(string orderNumber)
{
GetOrderBapiData data = new GetOrderBapiData();
ExternalAssembly.RunGetOrderBAPI(orderNumber, ref
data.PricingConditionTable, ref data.ScheduleLineTable, ref
data.HeaderStructure, ref data.LineItemTable ...);
return data; //after this returns, this object will be used in several
complex data mapping functions that need access to all the fields in
the data object.
}

Again, I realize this could be architected a different way, but in this
case, the class and its public fields are only there for encapsulation
and convenience...Imagine the maintenance nightmare of passing all 50
structures around to various functions to get the data mapping of all
these interdependent structures done!

Let it never be said that I'm defending the broad use of public
fields...I don't believe I've written one since my beginning days in
Java. I even took the time to cook up several VS macros to
auto-generate my properties for me. All I'm saying here is that there
are circumstances in which their use is not worthy of death by fire, as
you seem to imply :-)

"The example you cite seems like the epitome of poor excuses to me."
No, the epitome of poor excuses in this situation would also be the
most common one...Plain old laziness. It's easier to write one line of
code for a field than 5 for a property. Interestingly, I AM guilty of
this one when it comes to making my events public and not putting the
add/remove accessors around them, which is, after all, pretty much the
same thing.

-Jared

[JaredHite1]

"It is better to understand the underlying principle than to simply
adhere to a set of rules."
I couldn't agree more. In this case, I agree wholeheartedly with the
principle, I just don't care for the lack of wiggle room in the rule.
Maybe with some searching I could come up with a better
counter-example, but this just happened to be one I've seen in real
life.

-Jared

[JaredHite1]

Correcting myself before anyone else gets to it...

"Imagine the maintenance nightmare of passing all 50 structures around
to various functions to get the data mapping of all these
interdependent structures done! "
Most of the maintenance nightmare could just as easily be avoided using
parameters...The fields could being declared and instantiated in the
GetOrderBapiData function, then assigned into the return object after
the call. That approach would result in "only" an additional 100 lines
or so per function that needs to pass the structure's fields byref
(explicitly) to some function outside of my control.

-Jared

[Jon Skeet [C# MVP]]

JaredHite1 <ja***@sharingds.org> wrote:

My mother warned me not to disagree with MVPs...I should have listened
:-) But I'm not sure you understood my example...I'm not talking about
passing reference objects to functions, but passing by reference
explicitly using the ref keyword, which results in a compile-time error
when you try to do it with properties. Maybe It will be more clear if
I illustrate it:

//Code in an assembly far outside of my control:
public void RunGetOrderBAPI(string order number,
ref PricingConditionTable,
ref ScheduleLineTable,
ref HeaderStructure,
ref LineItems,
Functions like this to get tables and structures may have 50
parameters, each of which is a fairly hefty object that is passed by
ref
) {}
I would suggest wrapping that method in another method which deals with
the fact that it's a terribly signature. The "fairly hefty" part
worries me, because it suggests that you think there would be a penalty
in passing that object reference by value. Maybe you *do* understand,
and you're just not expressing that bit well.

Anyway, when a method takes 50 parameters, that's screaming to have a
class encapusulating those parameters - especially when most of them
are passed by ref.

Your encapsulating class can then have member variables, and have a
method which calls RunGetOrderBAPI itself, passing its member variables
by reference. You then expose those member variables through
properties, which gives you control again in the way that properties
normally do.

<snip>
Again, I realize this could be architected a different way, but in this
case, the class and its public fields are only there for encapsulation
and convenience...Imagine the maintenance nightmare of passing all 50
structures around to various functions to get the data mapping of all
these interdependent structures done!
So you've already got your encapsulating class. Now, compare the
following code snippets:

Your current code:
//in some data access class
public GetOrderBapiData GetOrder(string orderNumber)
{
GetOrderBapiData data = new GetOrderBapiData();
ExternalAssembly.RunGetOrderBAPI(orderNumber, ref
data.PricingConditionTable, ref data.ScheduleLineTable, ref
data.HeaderStructure, ref data.LineItemTable, ... (lots more stuff
here)
}

and this:

public OrderBapiData GetOrder (string orderNumber)
{
OrderBapiData data = new OrderBapiData();
data.Load (orderNumber);
}

I know which I'd prefer to see :)

The method call taking 50 parameters would only occur in a single
place, within the class which knows about those fields.

<snip>
"The example you cite seems like the epitome of poor excuses to me."
No, the epitome of poor excuses in this situation would also be the
most common one...Plain old laziness. It's easier to write one line of
code for a field than 5 for a property. Interestingly, I AM guilty of
this one when it comes to making my events public and not putting the
add/remove accessors around them, which is, after all, pretty much the
same thing.

No, it's not the same thing. When you make an event public, it's not
making any fields public - it's just autogenerating the add/remove
methods for you. At a later date, you could make those add/remove parts
explicit and nothing would break (you'd have source and binary
compatibility). Also, apart from the thread-safety aspect, the default
implementation of add/remove is fine.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[JaredHite1]

"The "fairly hefty" part worries me, because it suggests that you think
there would be a penalty in passing that object reference by value.
Maybe you *do* understand, and you're just not expressing that bit
well."
I see how I implied that...I do understand that only the reference is
copied, and not the object itself. The fairly hefty bit muddied the
waters, and didn't really have any purpose.

"Your encapsulating class can then have member variables, and have a
method which calls RunGetOrderBAPI itself"
OK, I admit I didn't think of that, probaby because as a general rule,
I've avoided mixing the data layer with the data access layer of my
applications. But I suppose that since the only purpose of the data
here is to provide data access, the rule doesn't really apply.

Thanks!
Jared

[Lucian Wischik]

"Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote:

A fundamental principle of object orientation is encapsulation.
An object should have full control over it's data at all times.
The get-set accessor enables an object to ensure that it must do some
intelligent processing when an external object tries to update it's data.

A fundamental principle of programming is not to introduce needless
complexity. If your original design used no such intelligent
processing, then you should start with just plain fields. If you want
to add validation later on, then you can easily change it to
properties later on without breaking dependant code. (except for the
case where you use them as "ref" parameters, but that's not serious,
and it's good to defer this extra work until later).

The good place NOT to use properties is when you're using an object
just as a collection of parameters that you're passing around. In C
you'd represent this as a struct. And all the Win32 functions take
such structs as arguments. Because they're just simple structs you can
see them in their entirety on a quarter of your screen. That makes
them easier to understand.

I think that this "simplicity imperative" overrides the "OO
encapsulation imperative". And it highlights one of the areas where
traditional OO is bad. When your chosen language is bad at a
particular task, you accept it disdainfully with a bargepole -- you
don't embrace it wholesale.

--
Lucian

[Jon Skeet [C# MVP]]

Lucian Wischik <lu***@wischik.com> wrote:

<snip>

I think that this "simplicity imperative" overrides the "OO
encapsulation imperative". And it highlights one of the areas where
traditional OO is bad. When your chosen language is bad at a
particular task, you accept it disdainfully with a bargepole -- you
don't embrace it wholesale.

I would say that it's not that traditional OO is bad - it's that C# and
some other OO languages are bad in this area. They make it hard to do
the "pure" thing. If declaring a simple property were no harder or more
complex than declaring a field, it would surely be a no brainer.

I used to be opposed to the idea of a simple property declaration, but
I now believe it would be really nice to be able to do something like:

public int Foo { get; private set; }

Perhaps there should be a way of specifying the name of a field to
create under the hood, so that if you *did* want to use the field
directly instead of the property somewhere, it would be okay.

public int Foo, m_foo { get; set; }

(In this one, the setter is public too.)

I'm not convinced of the syntax of the latter version, but I'm sure
others could improve it.

Of course, if attributes were used instead, we could do it really
easily without worrying about keywords:

[SimpleProperty(Foo, SetterAccess=AccessLevel.Private)]
int m_foo;

Not as neat as a language element which was designed in from the start,
but less difficult to work out in terms of conflicts etc.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Martijn Mulder]

> A fundamental principle of programming is not to introduce needless

complexity. If your original design used no such intelligent
processing, then you should start with just plain fields. If you want
to add validation later on, then you can easily change it to
properties later on without breaking dependant code <snip>

Existing dependant code does not access the data via the properties but
directly. So when you add validation in the properties later on, it suggests
that all access to the data is validated, while in fact only new code can
use this facility and old code simply does not use it. You give two ways to
access the same data, one validated, the other not and you know what that
will bring you.
The good place NOT to use properties is when you're using an object
just as a collection of parameters that you're passing around. In C
you'd represent this as a struct. And all the Win32 functions take
such structs as arguments. Because they're just simple structs you can
see them in their entirety on a quarter of your screen. That makes
them easier to understand.

Properties do provide a very brief syntax, if you accept some squeezing. My
properties typically look like this

class MyClass
{
//data members x, y, z. Private by default
int x,y,z;

//public properties
public X{get{return x;}set{x=value;}}
public Y{get{return y;}set{y=value;}}
public Z{get{return z;}set{z=value;}}
}
That's easy enough to understand

[Lucian Wischik]

"Martijn Mulder" <i@m> wrote:

Existing dependant code does not access the data via the properties but
directly. So when you add validation in the properties later on, it suggests
that all access to the data is validated, while in fact only new code can
use this facility and old code simply does not use it.
???
The old code looked like this:
(property) public int x;
(dependant-code) int y = myObject.x;

The new code looks like this:
(property) private int _x; public int x {get{return _x;} set{...}}
(dependant-code) int y = myObject.x;

So old code will fail to load/run, rather than "simply not using it".

Properties do provide a very brief syntax, if you accept some squeezing. My
properties typically look like this

class MyClass
{
//data members x, y, z. Private by default
int x,y,z;

//public properties
public X{get{return x;}set{x=value;}}
public Y{get{return y;}set{y=value;}}
public Z{get{return z;}set{z=value;}}
}
That's easy enough to understand

class MyClass {public int x,y,z;}

That's easier.

--
Lucian

[Martijn Mulder]

"Lucian Wischik" <lu***@wischik.com> schreef in bericht
news:22********************************@4ax.com...

"Martijn Mulder" <i@m> wrote:

Existing dependant code does not access the data via the properties but
directly. So when you add validation in the properties later on, it
suggests
that all access to the data is validated, while in fact only new code can
use this facility and old code simply does not use it.

???
The old code looked like this:
(property) public int x;
(dependant-code) int y = myObject.x;

The new code looks like this:
(property) private int _x; public int x {get{return _x;} set{...}}
(dependant-code) int y = myObject.x;

So old code will fail to load/run, rather than "simply not using it".

Properties do provide a very brief syntax, if you accept some squeezing.
My
properties typically look like this

class MyClass
{
//data members x, y, z. Private by default
int x,y,z;

//public properties
public X{get{return x;}set{x=value;}}
public Y{get{return y;}set{y=value;}}
public Z{get{return z;}set{z=value;}}
}
That's easy enough to understand

class MyClass {public int x,y,z;}

That's easier.

--
Lucian

You're right. Short is beautiful.