Re: Another controversial question
Re: Another controversial question
- Subject: Re: Another controversial question
- From: Chris Gehlker <email@hidden>
- Date: Mon, 03 Sep 2001 17:35:39 -0700
On 9/3/01 9:56 AM, "Ondra Cada" <email@hidden> wrote:
>
"Encapsulation" means very plainly "Nobody should mess up with the object's
>
guts directly; there is the object's own API for that".
"Encapsulation" doesn't very plainly mean anything. There is a raging debate
how best to define it in many newsgroups. There is a camp that defines it in
terms of access and a camp that defines it in terms of consistency. I
clearly favor the consistency camp. You seem to be in the access camp.
That's fine if you understand both positions and have really thought about
it. It's maybe not so good if you are just responding out of habit.
The argument that I find very persuasive goes like this:
Consider on one side a class with public getters and setters for all of it's
instance variables and on the other side a file containing a struct and some
functions that manipulate it's members. Is there any practical advantage to
using one over the other? Is it easier to isolate bug with the class or to
change the implementation without changing the interface?
>
Inicidentally, from the very same viewpoint a C++ inline accessor "method"
>
_DOES_ violate encapsulation, since it is compiled to a direct access to an
>
object's property. Actually, even C++ virtual methods do violate
>
encapsulation, since they again access object's inside directly (they are
>
compiled to something very like to "(*object)[N](arguments)" with a constant
>
N).
Since you know that this statement is be very controversial you must know
that there is no widely accepted definition of "encapsulation."
>
CG> It doesn't matter much, though. We agree its a bug.
>
>
I guess we do agree, though I don't understand _WHAT_ you mean by "its"
>
here: accessing directly some data in an object? If so, of course.
"Its" referred to the the definition of "encapsulation" that you use. It was
pretty obvious from other stuff in your post that you code according to
mine.
>
Please take no offence, but I am starting to be _really sickened_ by all of
>
you who are lazy enough to read, blaming Apple for a bad docs. True is that
>
*SOME* things are documented really badly; though, for I guess fifty rants of
>
"bad docs" here, some 49 is of things which are, instead, documented quite
>
well. Like:
Excuse me all to hell. Before I complained about the documentation I had
opened:/Developer/Documentation/Cocoa/TasksAndConcepts/ProgrammingTopics/Key
ValueCoding/KeyValueCoding.html
Which just says "Description forthcoming."
But being a persistent cuss I had also found
System/Library/Frameworks/Foundation.framework/Versions/C/Resources/English.
lproj/Documentation/Reference/ObjC_classic/Protocols/NSKeyValueCoding.html
In the second paragraph and again under accessInstanceVariablesDirectly that
the default is to directly access instance variables if there is no defined
accessor. No run time error is mentioned.
Then you post and say that the default is to generate a run time error if
there is no accessor.
So I believe you and complain about the docs.
So you say you are "_really sickened_" because I took you word for
something when it contradicted the docs.
--
In the midst of great joy, do not promise anyone anything. In the midst of
great anger, do not answer anyone's letter. -Chinese proverb