Avoid protected data

Revision as of 01:58, 20 October 2010

All data in a base class should be private; do not use protected data. --Riel's Heuristic 5.3, Arthur Riel 1996

• data - The fields defined within a class
• private - To restrict accessibility to within an instance of a class
• protected - To restrict accessibility to within an instance of a class, and to instances of inheriting classes

Description

Riel's Heuristic #5.3 demands that access to a class's fields should be restricted to instances of that class. Inheriting classes should access these fields via accessor methods only. By restricting a subclass's field accesses in this way, a designer is free to change the manner in which the data is stored within the base class, with minimal effect on subclasses.

Discussion

The reasoning behind this maxim suggests that we should avoid imposing rigid designs higher up in the inheritance hierarchy. It ties in with Ken Auer 1995, suggesting we follow the Defer identification of state variables pattern. According to this reasoning, using "protected" (and thus object encapsulation) reduces design flexibility by coupling subclasses to the state implementation of the base class. This seems to be the conflict of this maxim with object encapsulation - it is seen as inflexible. As a consequence, this maxim promotes class encapsulation.

See Also

• Information hiding
• Minimize accesses to variables
• Getters and setters
• Riel's heuristics
• Design maxims
• Defer identification of state variables pattern

Conflicts with

Object & Class encapsulation. See:Encapsulation boundary