Re: Is encapsulation deprecated in ObjC?
Re: Is encapsulation deprecated in ObjC?
- Subject: Re: Is encapsulation deprecated in ObjC?
- From: "Dennis C. De Mars" <email@hidden>
- Date: Thu, 16 Aug 2001 10:02:29 -0700
on 8/16/01 9:31 AM, Chris Gehlker at email@hidden wrote:
>
On 8/16/01 7:47 AM, "Lloyd Sargent" <email@hidden> wrote:
>
>
> I'm not going to argue one way or the other, but apparently in the OOP
>
> community there are two camps: one that likes public accessors and
>
> others that don't. Personally, I learned that the point of OOP was that
>
> you TOLD and object to do something (what I think of as 'active') vs.
>
> setting/asking it for its contents (what I think of as 'passive').
>
> However, sometimes that doesn't always fly. For example, how do I
>
> determine if a button is in a particular state? Uh, er, I guess I have
>
> to ask it for it's value <shuffle's feet and whistles tunelessly>. :^)
>
>
>
> The problem is that sometimes ya' gotta have public accessors, IMHO.
>
>
That helps clarify my thinking but it still doesn't completely answer my
>
question. For one thing, I should have focused on setters. I personally
>
don't see any reason at all why getters could be a problem since they don't
>
change the object's state. I have heard an argument that even getters are
>
bad but I don't think I can do it justice.
Objective-C allows you to make instance variables private, so in this sense
it supports data-hiding (whether this is synonymous with "encapsulation" I'm
not sure). As for public accessors, if you make an instance variable private
and then provide public accessors I would argue that you _have_ implemented
encapsulation.
Suppose you have a class that needs to inform some other object(s) when
certain data in the object is changed. If you only allow the data to be
changed via accessor methods, then you can have the accessor method do the
notification, whereas if the instance variables had been public, someone
could come along and set them without the class "knowing" about it.
Also, it allows you to change the implementation of the class without
disturbing the API. For instance, you might have an accessor method that
fetches the state of a button simply by returning the value of an instance
variable. But suppose you decided to change the way the state was determined
for that button class by deriving the state from other information and
eliminating the state instance variable. You could go ahead and do that and
rewrite the accessor method without affecting the user of the class, whereas
if the state instance variable had been publicly available (i.e. accessible
outside of the accessor method), you would be stuck with it.
As for accessor methods that simply set and change the instance variable
they are associated with, these are cases where the class author decided
this was the safe/appropriate thing to do. But only the class author knows
which variables can be set this way and by making the variables private and
writing accessor methods, the class author enforces this knowledge and can
change those variables and make those accessor methods do something more
complex at any time without the user of the class being aware of it.
Of course, if you mechanically create accessor methods for every instance
variable you have, I suppose you have in effect thrown encapsulation out the
window, although even then you have the power to modify those accessor
methods in the future, which is still more flexible than just making the
instance variables public. But I don't think most programmers do this. I can
assure you that the Cocoa classes have scads of private instance variables
with no public accessors. If you saw some example code where the instance
variables were all given accessor methods, that is probably attributable to
the simplicity of the examples; perhaps no instance variables were needed
other than the ones that were of interest to users of the class. Even there,
keeping the instance variables private and providing access to those
variables _only_ through accessor methods is good OO practice.
- Dennis D.