Attributes and Properties

[Chuck Bowling]

Is there any justification - from an OOP perspective - for wrapping an
attribute in a Property beyond the ability to restrict access?

private int myInt;

public int MyInt
{
get { return myInt; }
set { myInt = value; }
}
Is there any value in the above as opposed to simply making myInt public?

[JV]

If you just make your integer public, you lose any/all control over who
accesses it and how. This may or may not ever truly matter in the long run.
All depends.

If you wrap it in a property, you will always be able to address problems
down the road if/when they occur. My advice is just wrap that sucker. It's
not much work and you may someday be REALLY REALLY glad you did.

And, of course, for certain situations that is your only option...for
example, when writing a server control for asp.net, or creating an object
that may be data bound.
"Chuck Bowling" <ch**********@sbcglobal-NO-SPAM.net> wrote in message
news:ev****************@tk2msftngp13.phx.gbl...

Is there any justification - from an OOP perspective - for wrapping an
attribute in a Property beyond the ability to restrict access?

private int myInt;

public int MyInt
{
get { return myInt; }
set { myInt = value; }
}
Is there any value in the above as opposed to simply making myInt public?

[Mohammad]

>From an OOP perspective, there are some practical considerations that
would make properties "safer" in the long term. For example, from a
pure OOP point of view, all classes should be accessed through
interfaces, and an interface can only define properties and methods,
not fields.

There is one consideration that should be taken into account: data
binding (at least in ASP.NET) only work with properties, not with
fields.

[Demetri]

One reason I can think of is if your class could be inherited (not sealed)
and you wanted to allow a property to have different implementation. Your
public field doesn't lend itself to polymorphism as greatly as an actual
property of a class.

Another instance would be if your property is defined in an interface.
Again, a class that uses your interface will want to have implementation code
for said property.

Bear in mind, not all properties are as simple as the one you used in your
example. Some need to execute code to format, perform conversions, or do some
other task before assigning or returning the value of the property.

At any rate, it's a good OOP habit to get into regardless of the
implementation of the property, be it complex or simple as your example.

-Demetri

"Chuck Bowling" wrote:

Is there any justification - from an OOP perspective - for wrapping an
attribute in a Property beyond the ability to restrict access?

private int myInt;

public int MyInt
{
get { return myInt; }
set { myInt = value; }
}
Is there any value in the above as opposed to simply making myInt public?

[Stephany Young]

In the example quoted, the only value is that access to the property would
be made with:

<object>.MyInt

whereas if the private member were public the access to it would be made
with:

<object>.myInt

Apart from that I see no value.

If you wanted to use a specific name for a member internally with the class,
but expose it with a completely different name then there would be value.

private int myInt;

public int YourInt
{
get { return myInt; }
etcetera

In many cases there is more processing to a property get clause than a
simple return and simalarly more proccessing than a simple assignment to a
property set clause.
"Chuck Bowling" <ch**********@sbcglobal-NO-SPAM.net> wrote in message
news:ev****************@tk2msftngp13.phx.gbl...

Is there any justification - from an OOP perspective - for wrapping an
attribute in a Property beyond the ability to restrict access?

private int myInt;

public int MyInt
{
get { return myInt; }
set { myInt = value; }
}
Is there any value in the above as opposed to simply making myInt public?

[Robert Sentgerath]

There are several advantages of using properties over data members:

o Only properties can be used directly with databinding.
o When later, you need to make access to a data member thread safe, it is
easy to add for example a lock(this) to the get/sets.
o from the OOP standpoint you can inherit from a class and override the
property get/sets
o properties allow you to later add validation rules to the set methods
without having to find all locations where a public data member is accessed.
Imaging all other actions you might want to later take when
someone/something gets/set your field: logging of that activity, triggering
some other events, assisting debugging by setting a breakpoint in the
get/sets, etc...
o If you think you can always later come back and change the public data
member to a property, you will have to recompile all other assemblies that
use your class that once had the public field. That is due to public fields
and properties not being binary compatible since properties are functions
whereas public fields are direct access.

The work to hack in the get/sets will become a right click and select from
the Refactor menu to wrap the private field. Once you develop the habit of
creating properties where you once used only public fields, it really takes
no time.

"Chuck Bowling" <ch**********@sbcglobal-NO-SPAM.net> wrote in message
news:ev****************@tk2msftngp13.phx.gbl...

Is there any justification - from an OOP perspective - for wrapping an
attribute in a Property beyond the ability to restrict access?

private int myInt;

public int MyInt
{
get { return myInt; }
set { myInt = value; }
}
Is there any value in the above as opposed to simply making myInt public?

[Chuck Bowling]

To JV, Mohammad, Demetri, Stephany Young, and Mr. Sentgerath; Thank you all
for the responses. So good food for thought.

FWIW, I usually wrap data members in Properties but until now I really
didn't have a good idea why I did it - only that I had read somewhere that
it was a good idea. I was aware that Properties allowed additional
processing on a member but beyond that wasn't clear on what other utility
they provided. Thanks.

"Robert Sentgerath" <rs*********@landstar.com> wrote in message
news:e$**************@TK2MSFTNGP14.phx.gbl...

There are several advantages of using properties over data members:

o Only properties can be used directly with databinding.
o When later, you need to make access to a data member thread safe, it is
easy to add for example a lock(this) to the get/sets.
o from the OOP standpoint you can inherit from a class and override the
property get/sets
o properties allow you to later add validation rules to the set methods
without having to find all locations where a public data member is
accessed.
Imaging all other actions you might want to later take when
someone/something gets/set your field: logging of that activity,
triggering
some other events, assisting debugging by setting a breakpoint in the
get/sets, etc...
o If you think you can always later come back and change the public data
member to a property, you will have to recompile all other assemblies that
use your class that once had the public field. That is due to public
fields
and properties not being binary compatible since properties are functions
whereas public fields are direct access.

The work to hack in the get/sets will become a right click and select from
the Refactor menu to wrap the private field. Once you develop the habit of
creating properties where you once used only public fields, it really
takes
no time.

"Chuck Bowling" <ch**********@sbcglobal-NO-SPAM.net> wrote in message
news:ev****************@tk2msftngp13.phx.gbl...

Is there any justification - from an OOP perspective - for wrapping an
attribute in a Property beyond the ability to restrict access?

private int myInt;

public int MyInt
{
get { return myInt; }
set { myInt = value; }
}
Is there any value in the above as opposed to simply making myInt public?

[Robert Sentgerath]

There are several advantages of using properties over data members:

o Only properties can be used directly with databinding.
o When later, you need to make access to a data member thread safe, it is
easy to add for example a lock(this) to the get/sets.
o from the OOP standpoint you can inherit from a class and override the
property get/sets
o properties allow you to later add validation rules to the set methods
without having to find all locations where a public data member is accessed.
Imaging all other actions you might want to later take when
someone/something gets/set your field: logging of that activity, triggering
some other events, assisting debugging by setting a breakpoint in the
get/sets, etc...
o If you think you can always later come back and change the public data
member to a property, you will have to recompile all other assemblies that
use your class that once had the public field. That is due to public fields
and properties not being binary compatible since properties are functions
whereas public fields are direct access.

The work to hack in the get/sets will become a right click and select from
the Refactor menu to wrap the private field. Once you develop the habit of
creating properties where you once used only public fields, it really takes
no time.

"Chuck Bowling" <ch**********@sbcglobal-NO-SPAM.net> wrote in message
news:ev****************@tk2msftngp13.phx.gbl...

Is there any justification - from an OOP perspective - for wrapping an
attribute in a Property beyond the ability to restrict access?

private int myInt;

public int MyInt
{
get { return myInt; }
set { myInt = value; }
}
Is there any value in the above as opposed to simply making myInt public?

[Chuck Bowling]

To JV, Mohammad, Demetri, Stephany Young, and Mr. Sentgerath; Thank you all
for the responses. So good food for thought.

FWIW, I usually wrap data members in Properties but until now I really
didn't have a good idea why I did it - only that I had read somewhere that
it was a good idea. I was aware that Properties allowed additional
processing on a member but beyond that wasn't clear on what other utility
they provided. Thanks.

"Robert Sentgerath" <rs*********@landstar.com> wrote in message
news:e$**************@TK2MSFTNGP14.phx.gbl...

There are several advantages of using properties over data members:

o Only properties can be used directly with databinding.
o When later, you need to make access to a data member thread safe, it is
easy to add for example a lock(this) to the get/sets.
o from the OOP standpoint you can inherit from a class and override the
property get/sets
o properties allow you to later add validation rules to the set methods
without having to find all locations where a public data member is
accessed.
Imaging all other actions you might want to later take when
someone/something gets/set your field: logging of that activity,
triggering
some other events, assisting debugging by setting a breakpoint in the
get/sets, etc...
o If you think you can always later come back and change the public data
member to a property, you will have to recompile all other assemblies that
use your class that once had the public field. That is due to public
fields
and properties not being binary compatible since properties are functions
whereas public fields are direct access.

The work to hack in the get/sets will become a right click and select from
the Refactor menu to wrap the private field. Once you develop the habit of
creating properties where you once used only public fields, it really
takes
no time.

"Chuck Bowling" <ch**********@sbcglobal-NO-SPAM.net> wrote in message
news:ev****************@tk2msftngp13.phx.gbl...

Is there any justification - from an OOP perspective - for wrapping an
attribute in a Property beyond the ability to restrict access?

private int myInt;

public int MyInt
{
get { return myInt; }
set { myInt = value; }
}
Is there any value in the above as opposed to simply making myInt public?