Avoid protected data
From CSSEMediaWiki
(Difference between revisions)
m |
|||
| Line 1: | Line 1: | ||
| − | + | :''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 | *''data'' - The fields defined within a class | ||
*''private'' - To restrict accessibility to within an instance of a class | *''private'' - To restrict accessibility to within an instance of a class | ||
| Line 13: | Line 14: | ||
== Conflicts with== | == Conflicts with== | ||
Object encapsulation. See:[[Encapsulation boundary]] | Object encapsulation. See:[[Encapsulation boundary]] | ||
| + | |||
| + | [[Category:Riel's heuristics]] | ||
Revision as of 00:01, 21 July 2009
- 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
Conflicts with
Object encapsulation. See:Encapsulation boundary
