What's with Get and Set? Why bother?

  • Thread starter Thread starter Bruce W.1
  • Start date Start date
B

Bruce W.1

Why does .Net use Get and Set accessors?

So a class has a property, why not just change or get it directly like this:
MyClass.MyValue = value;
Rather than:
Set
{
MyValue = value;
}

Accessing it with Get and Set lets you change permissions, other than
that I don't see the point.

So why does .Net use Get and Set accessors?

Thanks for your help.
 
Because you can perform validations on the data being passed in. You way
does not allow us to interrogate the value coming in and possibly reject it.
Also, this way allows us to invoke other related code that may need to
change based on the property value being changed (ie. setting property A to
false means that property B must also be false because they work together).
 
It allows you to write code that executes everytime the property is read or
set. The actual data behind the property could be in the registry, or in a
database, or on another machine in another country. The user just does
MyObject.MyProperty = blah, or blah = MyObject.MyProperty. It also lets you
do data validation. If the value must be between 1 and 50, and the user
does MyObject.MyProperty = 75, you could adjust it to 50 before storing it,
set a .Status property to an InvalidData enum, pop up a MessageBox, etc...
If the user were just accessing a public member variable, these activities
would be nearly (if not definately) impossible.

Did that help to explain it?
 
If you're really in a pickle about it, then don't bother with properties -
just expose those member variables as Public.

But that breaks rules of encapsulation. At least if you use properties, you
can declare a property as readonly, writeonly, as well as adding validation
code etc. My only gripe with the current method is that you can't put code
anywhere else other than within the Get and Set blocks... would be nice to
declare variables that are used by both but that's just me being awkward!

HTH
 
I actually think this is a really good gripe; the advantages of properties take a hit because of
it, for example:

public class Foobar {
private string m_foo = string.Empty;
public string Foo {
get { return m_foo; }
set
{
// do some fancy validation... perhaps to keep Foo from == null
m_foo = value;
}
}

private void BuggyMethod()
{
m_foo = null;
}
}

I think it would be "better" to be able to isolate the actual "property" (in this case m_foo)
inside the property definition:

public string Foo {
private string m_foo = string.Empty;
get { ... }
set { ... }
}

Now that doesn't look so great; but if inner classes and properties were more alike one could get
used to it.

Scott
 
Although I understand your request, I think it is better as it is. It
is assumed that I, as the programmer of the class would know what is
or is not allowable for the value of m_foo, so would not set it to
null (or nothing). Only when there is a publicly addressable inteface
(accessors) do I need to enforce those rules.


If I want to be held by the hand even within the code, I could have
code that is called by both the validation part of the set accessor
and whatever other code can manipulate the property. You can still
hose it if you want, but even in your example, code inside Foo section
could concievably bugger it up.
 
I guess I wasn't proposing a replacement; but I like properties in general and having them act more
like a first class part of the language (rather than just a neat compiler trick) seems like an
worthwhile thing to do -- especially for simple single field member like my illustration.

I agree I'd like the freedom to work both ways; but I also have run into a couple of classes where
the original writer, I'd never do such a thing :), was lazy and didn't always encapsulate access --
thus when the implementation of the the property itself changed the code broke. I've also noticed a
lot of example code where the author defines a property, but then references the member field in
their code; I'd like to be able to write classes where that wasn't possible -- without preventing
others from doing it.

Scott
 
Back
Top