Contain contents not parents
From CSSEMediaWiki
(Difference between revisions)
m (Reverted edits by Ebybymic (Talk); changed back to last version by Stephen Fitchett) |
|||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
:''A class must know what it contains, but it should never know who contains it.'' --Riel's Heuristic 4.13, [[Arthur Riel 1996]] | :''A class must know what it contains, but it should never know who contains it.'' --Riel's Heuristic 4.13, [[Arthur Riel 1996]] | ||
− | This heuristic refers to the idea that classes should not know what objects contain them as this makes them far less reusable | + | This heuristic refers to the idea that classes should not know what objects contain them as this makes them far less reusable. If a class is designed for a specific use and is dependent on a parent object, it can't then be used inside a different type of parent object. For example, Riel uses the example of a ''BedRoom'' containing an ''AlarmClock''. The ''BedRoom'' object must know about the ''AlarmClock'' object inside it, but if ''AlarmClock'' is dependent on ''BedRoom'' then it can't then be used inside a ''TimeLockSafe''. |
The [[Chain of Responsibility]] design pattern violates this heuristic. | The [[Chain of Responsibility]] design pattern violates this heuristic. | ||
[[Category:Riel's heuristics]] | [[Category:Riel's heuristics]] |
Latest revision as of 03:11, 25 November 2010
- A class must know what it contains, but it should never know who contains it. --Riel's Heuristic 4.13, Arthur Riel 1996
This heuristic refers to the idea that classes should not know what objects contain them as this makes them far less reusable. If a class is designed for a specific use and is dependent on a parent object, it can't then be used inside a different type of parent object. For example, Riel uses the example of a BedRoom containing an AlarmClock. The BedRoom object must know about the AlarmClock object inside it, but if AlarmClock is dependent on BedRoom then it can't then be used inside a TimeLockSafe.
The Chain of Responsibility design pattern violates this heuristic.