Avoid protected data

From CSSEMediaWiki
Revision as of 02:02, 20 October 2010 by Filip Kujikis (Talk | contribs)
Jump to: navigation, search
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

Contents

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 design decisions 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 shared state implementation of the base class. This is the conflict of this maxim with object encapsulation - it is seen as inflexible. As a consequence, this maxim promotes class encapsulation.

See Also

Conflicts with

Object & Class encapsulation. See:Encapsulation boundary

Personal tools