Sponsored Link •
|
Advertisement
|
Advertisement
|
This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.
Message:
I think the thing that nobody is mentioning is the fact that you do get a level of abstraction using get and set methods instead of just exposing the data directly. You can still change the representation of the data underneath or derive it without changing the get/set API, so client code can potentially remain as is. I would say exposing the data (i.e. making it public) is evil, but using set/get methods is merely dangerous, but at times necessary. > > Thanks for the reply Craig. I didn't think that I would > I'm just slow to respond sometimes. ;-) > > Perhaps, but from a pure OO standpoint it seems to me that it would be the most "correct" answer (especially if you have other classes that can accept Weight as a method parameter). > > Not true...addMyWeightToRunningSum( 0 ) is simply getWeight() in disguise. > > Precisely. The question is whether the get/set methods truly break encapsulation by unnecessarily exposing class data or whether they act as a service of the class by allowing controlled access to a meaningful subset of that data. In the case of a bank account, I would argue that access to balance information through a get method (I don't see the need for a direct set method off the top of my head) is a desired service of the class. > More food for thought. > Craig
Replies: |
Sponsored Links
|