Re: Is encapsulation deprecated in ObjC?
Re: Is encapsulation deprecated in ObjC?
- Subject: Re: Is encapsulation deprecated in ObjC?
- From: Lloyd Sargent <email@hidden>
- Date: Thu, 16 Aug 2001 17:25:27 -0500
On Thursday, August 16, 2001, at 12:07 PM, cocoa-dev-
email@hidden wrote:
Message: 6
Date: Thu, 16 Aug 2001 09:31:58 -0700
Subject: Re: Is encapsulation deprecated in ObjC?
From: Chris Gehlker <email@hidden>
To: Cocoa DEV <email@hidden>
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.
Sometime you want to programtically change the state of a button. For
example, let's say you can open a drawer via menu and via toggle button.
Would be nice to have that button stay in sync with the state of the
drawer. In which case, looks like you gotta set the button state.
Secondly, as was stated earlier, public accessors may actually hide a
whole lotta' stuff underneath. You don't know. And that is fine,
because, for the most part, you don't need to know <grin>.
But lets take your switch controller example. It could be written like
this:
<snipped>
And I know people who would actually write it that way. There argument
goes
something like:
It's important that any code dealing with the switch be isolated in
ParanoidController. That way if any bugs crop up that have to do with
the
switch I know they are isolated in ParanoidController and half my work
is
done.
Okay, but that is not the total argument. The rest of the argument goes
"plus if I need to make changes later in life, the interface still
remains the same". Remember that 90% of the work is NOT in writing the
code the first time, it is maintaining the bugger over it's lifetime
(which I guarantee you is ALWAYS longer than projected! <grin>).
I don't reject this argument out of hand but it leaves out something.
The
thing that's left out is:
"I have discovered though my own experience that the price I pay in
terms of
extra work and loss of code clarity is worth the benefits I get it
terms of
isolating bugs."
Depends on what you mean by code clarity. Personally, I like to write
code where
[object does_something];
rather than a whole string of
x=[object get_value];
// do a bunch of operations based on that
[object set_value];
As to which is more obscure, well, I think that is a matter of opinion -
and certainly out of the scope of Cocoa-Dev!
Cheers,
Lloyd
--------
Canna Software Development
"No llamas were served gin and tonics in the creation of this e-mail."