Avoid protected data
| (3 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 | + | 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== | ||
| Line 19: | Line 20: | ||
*[[Defer identification of state variables pattern]] | *[[Defer identification of state variables pattern]] | ||
== Conflicts with== | == Conflicts with== | ||
| − | Object encapsulation. See:[[Encapsulation boundary]] | + | Object & Class encapsulation. See:[[Encapsulation boundary]] |
[[Category:Riel's heuristics]] | [[Category:Riel's heuristics]] | ||
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
- 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
