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.
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.
