|
ms
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Attributes and PropertiesIs 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? 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. Show quote "Chuck Bowling" <chuckbowling@sbcglobal-NO-SPAM.net> wrote in message news:ev%23FLpXMFHA.4028@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? > >From an OOP perspective, there are some practical considerations that would make properties "safer" in the long term. For example, from apure 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. 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 Show quote "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? > > > 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. Show quote "Chuck Bowling" <chuckbowling@sbcglobal-NO-SPAM.net> wrote in message news:ev%23FLpXMFHA.4028@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? > 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. Show quote "Chuck Bowling" <chuckbowling@sbcglobal-NO-SPAM.net> wrote in message news:ev%23FLpXMFHA.4028@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? > > 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. Show quote "Robert Sentgerath" <rsentger***@landstar.com> wrote in message news:e$0UnYYMFHA.1268@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" <chuckbowling@sbcglobal-NO-SPAM.net> wrote in message > news:ev%23FLpXMFHA.4028@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? >> >> > >  |
|||||||||||||||||||||||
Other interesting topics