Encapsulation hides a class’s internal data representation and function implementations behind an interface. Public members provide access; private members remain available only inside the class, while protected members are available to subclasses. section 1.8 section 5.0
Implementation hiding improves class design by:
- Restricting the public surface to members that other code needs. section 5.0
- Preventing other classes from depending on inaccessible implementation details. section 5.0
- Allowing implementation changes without forcing dependent classes to change. section 5.0
- Containing variation through the Encapsulate What Varies principle. section 1.8
A date class
A Date object can keep year, month, and day private while exposing operations needed by the application, such as date arithmetic. Code using Date then depends on its date-oriented interface rather than its three-field representation. By contrast, exposing those fields would let other classes depend directly on the representation and make later changes more difficult. section 5.3
When implementation leaks
In a sports application, Baseball and Football each implement the same stadium venue algorithm. A venue change must be repeated in multiple classes, and another sport cannot easily reuse the behavior. The duplication and hardcoded behavior reveal missing encapsulation; moving the varying algorithms behind separate abstractions supports reuse and change isolation. section 8.2.2
Figure 5.5 A design of the book catalogue application with superclass Attributes and its subclasses. In the class diagram for Attributes, the symbol # indicates the member function is_match(Attributes) is protected—it is visible to the subclasses but hidden to other code.
The class diagram shows hidden superclass state alongside subclass extensions, with protected behavior visible to subclasses but hidden from other code. section 5.8
