Avoid protected data

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
 
(2 intermediate revisions by one user not shown)
Line 4: Line 4:
 
*''private'' - To restrict accessibility to within an instance of 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
 
*''protected'' - To restrict accessibility to within an instance of a class, and to instances of inheriting classes
 +
 
==Description==
 
==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.
 
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.
Line 9: Line 10:
 
== Discussion ==
 
== 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.
+
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==
 
==See Also==

Latest revision as of 02:05, 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

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