Re: Is encapsulation deprecated in ObjC?
Re: Is encapsulation deprecated in ObjC?
- Subject: Re: Is encapsulation deprecated in ObjC?
- From: Chris Gehlker <email@hidden>
- Date: Thu, 16 Aug 2001 11:27:39 -0700
On 8/16/01 10:47 AM, "Erik M. Buck" <email@hidden> wrote:
>
Sometimes the purpose of a class is to store a value. The class would be
>
useless if there was no "set" accessor to set the value.
>
>
Having a "set" accessor does not violate encapsulation. Directly setting an
>
instance variable via structure de-reference does violate encapsulation. A
>
"set" accessor perfectly preserves encapsulation. In the extreme case, a
>
class could be modified so that it no longer contains an instance variable,
>
and the corresponding "set" accessor could be modified to store the value
>
some other way (a dictionary, on disk, whatever). The code that uses the
>
class via the "set" accessor does not need to change. The "set" accessor
>
enhanced (created) the encapsulation that enabled the complete
>
re-implementation of a class without changes to code that uses the class.
Agreed
>
A Class that lets outsiders arbitrarily change its internal state is a bad
>
idea, unless the sole purpose of the class is to store an arbitrary state.
This is exactly what I was talking about. I'll pick on Apple since they are
big enough to take it. "Learning Cocoa" is full of simplistic setters that
are either not used in the sample code provided or used only in messages to
self. Furthermore, "Learning Cocoa" shows a technique for hiding methods in
the .m file but never applies that technique to those setters when they are
only used for messages to self. I started to conclude from that and a few
other examples that "It's a Cocoa convention to allow any object to mess
with another objects instance variables." I am quite relived to discover
that this tentative conclusion was wrong.
Thanks to everyone who helped straighten me out, both here and privately.
I reserve the right to flame both Apple and O'Reilly for messing with my
head. ;-)
BTW By "encapsulation" I meant only techniques for localizing and
abstracting the the code which can change an objects state. Hiding was also
a perfectly good word till the Java marketeers tried to make it seem like a
security measure.
It really should be sufficient, even on a large, multi-coder project, to
post signs saying "here be dragons." You shouldn't also have to erect fences
to keep out fools. Fools are just too smart at getting past fences. On that
basis, the key-value protocol does not violate encapsulation.
--
Adults are obsolete children.
-Dr. Seuss, humorist, illustrator, and author (1904-1991)