Theory of Encapsulation (was: Python vs. Ruby)

On Sep 1, 2003, at 3:29 PM, Sean O'Dell wrote:
> I remember back in the early 90's when I first dove into C++, there 
> seemed to be this thought process regarding OOP that went something 
> like: every object should be able to stand alone and interact rarely, 
> if ever, with anything else because that would break the object's 
> encapsulation.  I got that feeling from several texts, and I thought 
> it ludicrous at the time, and still do.  As things have evolved, it 
> seems common sense has stepped in to replace those purist theories, 
> but that article really took me back to that time.

Your original interpretation of the idea of encapsulation is one that I 
find held by a lot of folks that are new to object-oriented programming 
as you no doubt were in the early 90's. The ideas may have been 
presented improperly, or you may have misinterpreted them, but the 
ideas are not ludicrous unless you take them to an illogical extreme.

The idea is that every object should encapsulate a single idea, a 
cohesive concept, and should not have to look outside of itself to 
implement that concept.  If it does, then it will have to expose 
implementation details of itself to others through it's public 
interface.  Once you do that you have violated encapsulation.

It is not the idea that objects should interact with other objects 
rarely.  Obviously if that were true then you would have system that 
never did anything :-).

Rather it's along the same lines as Einstein's "Make things as simple 
as possible but no simpler", the idea is that objects should interact 
with other objects as little as possible and certainly NOT as a means 
of implementing behavior that should be the province of the object 
itself.

The other way I've heard it described is with the terms Coupling and 
Cohesion.  With all due respect to Dirk Gently, Coupling refers to the 
interconnectedness of all things within your program.  Cohesion refers 
to keeping related data, objects, behaviors, etc... together in tightly 
related groups.  An ideal system will have have very low coupling, 
passing as few messages between objects as necessary to get the job 
done, and have very high Cohesion, with related data and behaviors 
collected into logical containers.

As with most things, however, this is more an organizing principle than 
a hard and fast rule.  There are a thousand things that, under any 
given set of circumstances, can call for coupling than one might like 
to have, or less cohesion.  The concepts, however, are valuable to keep 
in mind.

Scott

.