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*@discussion s.microsoft.com > wrote in message
news:4C******** *************** ***********@mic rosoft.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 .SomeStructProp erty.SomeMethod () and
..SomeStructFie ld.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*@discussion s.microsoft.com > wrote in message
news:4C******** *************** ***********@mic rosoft.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******** ******@TK2MSFTN GP03.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*@discussion s.microsoft.com > wrote in message
news:4C******** *************** ***********@mic rosoft.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...Par ticularly 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***@sharingd s.org> wrote in message
news:11******** **************@ e56g2000cwe.goo glegroups.com.. .

"There is no good excuse for public variables in a well designed
object-oriented architecture."
That's a fairly bold statement...Par ticularly 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.