It Takes Two to Violate Encapsulation
Ever steal a candy bar when you were a kid? I did once. Now you have to give me some slack here because I was really, really upset. Bazooka Joe Bubble Gum had doubled its price from $.01 to $.02, and with my allowance at the time this was a significant hit. Never-the-less, I am the one who is guilty of violating encapsulation, not the store owner.
There are two players involved when you break encapsulation:
* the owner of the data
* the consumer of the data
In order to violate encapsulation, the object that has the data has to first expose it. But the real crime is committed when another object consumes it directly. The problem with violating encapsulation is that it causes structural changes within an object to ripple out to that object's consumers. The pain is felt in the data consumers, not in the data owner.
So fight that urge to steal the data. Just because the object is foolish enough to entrust you with it doesn't mean you should grab it. Add methods to that object (if you have access) and force it to manage its own data. When you do this, not only do you begin to minimize the ripple effects of structural changes, but you often enrich the interface of the object, clarifying its purpose to the rest of the system.
!commentForm
Great point! Periodically, in the agile community, people suggest that life would be easier if everyone made their methods and fields were public. It seems to work in the small, but I've heard of cases where it goes awry specifically because the social contract breaks down. People just decide to take some data. One could argue that we need protection specifically because of that, but I wonder.. it seems that when the social contract breaks down, protection doesn't really help either; it just all falls apart. I suspect that the truth is someplace in the middle.
This is a general question that comes to mind fairly often. Should code enable the designer's intent or enforce it? What else might enforce it ... code reviews? Is it a matter of how much you trust your peers to grok the goodness of your design?
I think that part of the problem is that people don't actually look at code, they just let the IDE auto-complete their request. Here is how I would choose the wrong path in an IDE: If I happened to be looking for some datum and the first few letters I typed only showed the data member then I'd assume that it was the only way to get my data. Likewise, if I typed the class name and a dot, maybe the data is the most obvious thing that appears in the list and I choose it.
On the other hand if I were working from an interface and not the class, maybe I wouldn't see the data members. The list after the dot would only show me the members in the interface. Mind you, that's working with a syntax-oriented language like Java or C++.
In a modern language like ruby or python or smalltalk, all the members area always public and without some convention (like python's prefixed underbar) I could let an IDE lead me astray, though in python I always look at the header file. This is also why I hate single-pane editors -- I need to see the code of the class I'm using along with the class I'm writing. I tend to not use an IDE for these most of the time because I don't need one. VIM is more than sufficient for python, and I used it in the little tiny bit of ruby I've done (almost none, really). I haven't done anything really in smalltalk other than read about it, but I wonder how the IDE handles the issue.
But I blame IDEs for many things. Until I started using refactoring tools, I was opposed to them on general principles.
On the other hand if I were working from an interface and not the class, maybe I wouldn't see the data members. The list after the dot would only show me the members in the interface. Mind you, that's working with a syntax-oriented language like Java or C++.
In a modern language like ruby or python or smalltalk, all the members area always public and without some convention (like python's prefixed underbar) I could let an IDE lead me astray, though in python I always look at the header file. This is also why I hate single-pane editors -- I need to see the code of the class I'm using along with the class I'm writing. I tend to not use an IDE for these most of the time because I don't need one. VIM is more than sufficient for python, and I used it in the little tiny bit of ruby I've done (almost none, really). I haven't done anything really in smalltalk other than read about it, but I wonder how the IDE handles the issue.
But I blame IDEs for many things. Until I started using refactoring tools, I was opposed to them on general principles.
Add Child Page to ItTakesTwo