The article made me think about something… In Python, you can choose to have one or two underscores in front of your variable of method name. Two underscores makes it more annoying than one underscore for the guy who’s trying to access the internals of your class. I’ve never found a use for it. Has anybody ?

The computer metaphor doesn’t translate all that well into OOP.
Like JJ said, as a class in your code, the computer would provide an upgrade method itself, without the need for you to mess with internals. Another possibility would be to have a helper for upgrading. For example, if a computer object would be created via the builder pattern, the builder might as well be the one to ask for upgrades. No need to get rid of encapsulation.

The GUI example:
This case is similar to one I encounter from time to time in programming forums.
The usual situation where someone asks for help is as follows: There is a BaseClass, and SubClass1 and SubClass2 derive from it.
Now, that someone creates a container for objects of BaseClass, containing both objects of the concrete classes SubClass1 and SubClass2. He then asks, for example, how to iterate over the container’s contents and execute specific actions depending on the concrete subtype.
In summary: Abstracting from the concrete classes, and then asking how to break the abstraction again. This can be solved in clean ways – double dispatch and visitor pattern come to mind, so you’re still fine using encapsulation. However, in my experience, most of the time someone does something like this, his/her concept is faulty somewhere.

Now back to the GUI example. Cross-platform GUI toolkits abstract away from the concrete operating systems. By their nature, they must thus provide the lowest common denominator. Now asking how to access an OS-specific function means “you’re doing it wrong” in my opinion. But as I said, this can be solved without breaking encapsulation.

PS: Ed’s comment was very interesting. And if you check his website you can see he’s a bit of an “encapsulation nerd”

This show that as a community we are all getting smarter and we might not need to be protected, but we are mature enough to take responsibility for our own development practices.

Thank you for your well-written and thoughtful article; it was most interesting and raises an important question.

I hope you don’t mind if I disagree with you on two points.

I largely agree with your definition of encapsulation, though I usually adhere to the International Organization for Standardization’s definition, whereby encapsulation is defined as being, “The property that the information contained in an object is accessible only through interactions at the interfaces supported by the object.”*

I disagree with you, however, about what encapsulation’s benefit is. You write, “The thought behind the whole idea of encapsulation is that when implementing a class, you protect it against misuse. You make sure that the user can’t break it.”

There are two issues here.

The first concerns ripple effect.

Back in 1974, Messrs Stevens, Myers and Constantine produced a paper in which were written two of the most important, consecutive sentences in the history of computing literature**:
“The fewer and simpler the connections between modules, the easier it is to understand each module without reference to other modules. Minimizing connections between modules also minimizes the paths along which changes and errors can propagate into other parts of the system, thus eliminating disastrous, “Ripple effects,” where changes in one part causes errors in another, necessitating additional changes elsewhere, giving rise to new errors, etc.”
There are two types of source code dependency in a software system: a direct dependency (class A’s calling a method on class B realizes a direct dependency from A to B) and an indirect dependency (if class A calls a method on class B, and class B calls a method on class C, then A has an indirect dependency on class C).

When a change is made to a class, that there exists a probability that this change may trigger a ripple effect to those classes that depend (either directly or indirectly) on it, that is, if we change class C above then there is a probability that the change will propagate to class A, and there is a probability that the change will propagate to class B.

It can be proved that, given a change to any class X, the probability of this change’s propagation to classes indirectly dependent on class X cannot be greater than the probability of the change’s propagation to classes directly dependent on X. In almost all computer systems, furthermore, the probability of change propagation to indirectly-dependent classes is less that the probability of change propagation to directly-dependent classes.

Sounds obvious, but there it is.

The second issue is more subtle, and concerns potential.

Encapsulation, strange as it sounds, isn’t about the dependencies in a software system.

That is, it isn’t about the actual dependencies in a software system. The actual dependencies in a software system are simply a given. They exist and there’s nothing you can do about them. That they exist is merely evidence that encapsulation was powerless to prevent their existence.

Encapsulation, instead, is about potential dependencies: those dependencies that don’t yet exist in a system. Over these potential dependencies, encapsulation holds enormous sway: encapsulation makes potential dependencies probable or improbable. The point being, of course, that future, actual dependencies are more likely to be a subset of probable potential dependencies than they are to be a subset of the improbable potential dependencies.

Putting these two issues together we arrive at the benefit of encapsulation: encapsulation minimizes the number of potential, direct dependencies. In doing so, it minimizes the number of potential dependencies which carry the highest probability of change propagation. Given, furthermore, that every such potential change propagation is associated potential cost, then encapsulation minimizes the potential cost of ripple effect.

And that’s it.

Encapsulation, as described above, does not entail a means of encapsulation. How you implement your encapsulation is irrelevant, whether you use a compiler-enforced mechanism such as public/private accessors or a non-compiler-enforced mechanism such as leading underscores makes no difference, in theory, to the benefit of encapsulation. Despite the title, your article seems not present a case against encapsulation per se, rather it presents a case against compiler-enforced encapsulation and for non-compiler-enforced encapsulation (please correct me if I’m wrong).

Here, I have find my second disagreement with your writing.

You write of that, “If you ask yourself why this [non-compiler-enforced encapsulation] would be an improvement [over compiler-enforced encapsulation], you probably don’t know that in some rare cases, it is necessary to access the implementation.”

I would argue that you are correct: in rare cases, non-compiler-enforced encapsulation is superior; it lowers the cost of development by reusing some functionality that otherwise would have had to have been designed from scratch; let’s call this the Duplication Reduction case. Being superior in rare cases, however, does not mean that non-compiler-enforced encapsulation is outright superior. We must attempt to evaluate the costs and benefits of non-compiler-enforced encapsulation before we can claim that it is an, “Improvement,” over compiler-enforced encapsulation.

Admitting the superiority of non-compiler-enforced encapsulation in rare cases is admitting at least equivalence with compiler-enforced encapsulation in the overwhelming majority of cases.

Consider, also, those rare cases when a designer incorrectly forms a dependency towards an encapsulated class and that class then changes, incurring a ripple-effect cost that would not have been incurred had compiler-enforced encapsulation been used and the designer had been forced to use the correct class; let’s call this the Inappropriate Dependency case.

The question perhaps boils down to the whether the probability of the Duplication Reduction case outweighs that of the Inappropriate Dependency case, or more particularly, if the cost-saving of the former outweighs the cost-increase of the latter, then non-compiler-enforced encapsulation is superior to compiler-enforced encapsulation. I’d like to show that this hypothesis is false.

We don’t, of course, have such probability figures available, but we can examine how we might expect such probabilities to behave as software systems scale, presuming the systems are well-encapsulated (either compiler-enforced or non-compiler-enforced) to begin with.

We note firstly that using non-compiler-enforced encapsulation does not guarantee that the Duplication Reduction case will be avoided. It is still possible, even in a system of non-compiler-enforced encapsulation, for a designer to simply overlook that some functionality he needs is encapsulated in the platform on which he’s working, causing him to write the same functionality again. There are two ways to prevent this. Either the designer must perform an exhaustive search of all the encapsulated functionality of the platform, or he must perform a random, non-exhaustive search. Both of these strategies fail to scale: for a large software system, the cost of an exhaustive search may quickly outweigh the cost of the duplicate development; and a random search will necessarily prove increasingly unsuccessful as the size of the system grows.

Furthermore, there is a limited subset of successful targets from which a designer may chose to benefit from the Duplication Reduction case: basically, there is a limited number of encapsulated classes which the designer could use instead of reproducing functionality, and this limited subset cannot grow as fast as the system itself grows (otherwise the designer end up with no product himself and just have the system). This successful subset decreases as a proportion of the system’s overall increasing size.

Thus as systems scale it seems the probability of the Duplication Reduction case falls.

On the contrary, as systems scale, the probability of the Inappropriate Dependency case does not seem to fall. Given that the Inappropriate Dependency case is essentially a failure case (in that it costs more money) then the target space from which the unwary designer may chose classes on which to form inappropriate dependencies scales precisely with the system size: as the system’s size increases, so too does the space of available, encapsulated classes towards which costly dependencies may be formed. (Indeed there is a wealth of evidence from poorly encapsulated systems that such inappropriate dependencies lead to Big-Ball-Of-Mud syndrome and hopelessly expensive maintenance cycles.)

So it seems that, for increasingly large systems, there must come a point when the probability of the Duplication Reduction case does not outweigh that of the Inappropriate Dependency case, and thus non-compiler-enforced encapsulation is not an improvement over compiler-enforced encapsulation.

Yours sincerely,

Ed Kirwan.

* “Information technology – Open Distributed Processing,” ISO/IEC 10746, 1998.

** “Structured design,” W. P. Stevens, G. J. Myers, and L. L. Constantine SD 13-2 p. 115ff, 1974.