Avoid protected data
From CSSEMediaWiki
(Difference between revisions)
m |
|||
| Line 12: | Line 12: | ||
*[[Riel's heuristics]] | *[[Riel's heuristics]] | ||
*[[Design maxims]] | *[[Design maxims]] | ||
| + | *[[Defer identification of state variables pattern]] | ||
== Conflicts with== | == Conflicts with== | ||
Object encapsulation. See:[[Encapsulation boundary]] | Object encapsulation. See:[[Encapsulation boundary]] | ||
[[Category:Riel's heuristics]] | [[Category:Riel's heuristics]] | ||
Revision as of 01:42, 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.
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 encapsulation. See:Encapsulation boundary
