We have developed many bad habits over the years as OOP has proliferated frameworks and tools. In this episode, we look at the practical side of data encapsulation and access levels like private, protected, and public.
Tools Are A Beginning
Modern frameworks and tools provide ways to generate a general object-oriented solution quickly. Therefore, the tools will give us a start, but not the best solution. There are too many details the tools are not privy to that are essential to the best solution. We will make the best use of tools when we remember this fact. That means we can not only move forward with generated code. We must review what is provided and extend or remove details to fit our needs.
A perfect example of tools being a less-than-perfect fit is in data hiding. There are general assumptions made for accessors like getters and setters that should be refined. A solution does not know that you have a read-only property or one that should not be directly passed through on a request.
Data Encapsulation in a Nutshell
The goal of data encapsulation is for us to provide a form of just-in-time access to data within our system. This approach can also be viewed as making attributes and methods available on a need-to-know (or need-to-use) basis. Once we expose a method or value, we can not undo that. There are plenty of examples in frameworks where a feature or value is deprecated. That occurs when something was exposed that now should not be. Thus, the author is warning users that the deprecated element will be disappearing in the future. An ideal approach would be not to expose that feature in the first place.
