Member-only story
Three Thoughts on Encapsulation
There’s more to it than you think
Introduction
I remember quite well when the “light bulb went on” when it came to object-oriented programming (OOP). It happened while I was reading my favorite technical book of all time, Borland Pascal 7 Insider by Paul Cilwa.
It was a terrific book, full of excellent writing and exceedingly useful code. It illustrated the use of objects, including encapsulation, inheritance, and the hardest notion — polymorphism — beautifully.
It was a thrill to understand what all the hype was about, finally — and to realize the hype was worth it.
When someone approaches OOP, I think the first and most straightforward concept to get is the notion of encapsulation. In its most basic form, encapsulation is “information hiding” — the concealment of the internal workings of a class.
New developers seem to get that notion pretty quickly. They then move on to inheritance and polymorphism.
Encapsulation looks pretty simple. Here’s an example in TypeScript:
Easy, right? The internal data is private and protected from prying hands, while it is safely exposed as a property. It couldn’t be simpler.
1. It Includes Implementation Hiding
But I think that encapsulation is given short shrift as the “easy and basic” part of OOP. I believe that it is more important and more nuanced than it is given credit for.
Sure, it’s about information hiding. That’s the basic idea, naturally. But there’s more to it. I think that instead of thinking about encapsulation as “information hiding”, we should be thinking about it as “implementation hiding”.
Consider this class:
