Beware of many accessors
From CSSEMediaWiki
(Difference between revisions)
m (Reverted edits by Ebybymic (Talk); changed back to last version by Aidan Bebbington) |
|||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | If there are too many accessors for fields within a class (especially public accessors), it indicates that there are large numbers of requests requiring | + | :''Beware of classes that have many accessor methods defined in their public interface, many of them imply that related data and behavior are not being kept in one place.''--Riel's Heuristic 3.3, [[Arthur Riel 1996]] |
| + | |||
| + | If there are too many accessors for fields within a class (especially public accessors), it indicates that there are large numbers of requests requiring those fields. If a class is designed properly, only a small portion of the class should be usable by the external classes, other parts should be methods which assist the class to implement its behaviour. Too many accessors indicate that related data and behaviour are not placed together. In addition, too many client requests for field values either means the class is not supporting its own behaviour very well or some unrelated things have been put into the class (which breaks the [[Single responsibility principle]]). | ||
== See also == | == See also == | ||
| Line 5: | Line 7: | ||
* [[Getters and setters]] | * [[Getters and setters]] | ||
* [[Keep related data and behavior in one place]] | * [[Keep related data and behavior in one place]] | ||
| + | |||
| + | [[Category:Riel's heuristics]] | ||
Latest revision as of 03:10, 25 November 2010
- Beware of classes that have many accessor methods defined in their public interface, many of them imply that related data and behavior are not being kept in one place.--Riel's Heuristic 3.3, Arthur Riel 1996
If there are too many accessors for fields within a class (especially public accessors), it indicates that there are large numbers of requests requiring those fields. If a class is designed properly, only a small portion of the class should be usable by the external classes, other parts should be methods which assist the class to implement its behaviour. Too many accessors indicate that related data and behaviour are not placed together. In addition, too many client requests for field values either means the class is not supporting its own behaviour very well or some unrelated things have been put into the class (which breaks the Single responsibility principle).
