A class should not depend on its users
JaninaVoigt (Talk | contribs) (→See also) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Josh Oosterman) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 8: | Line 8: | ||
[[Image:2.2 example.png]] | [[Image:2.2 example.png]] | ||
| + | == Automatability == | ||
| + | This rule can be automated in the same way as the [[Acyclic dependencies principle]], looking for length 2 cycles in the directed graph of class coupling. | ||
== See also == | == See also == | ||
* [[Riel's heuristics]] | * [[Riel's heuristics]] | ||
* [[Acyclic dependencies principle]] | * [[Acyclic dependencies principle]] | ||
| − | * [[Circular | + | * [[Circular dependency]] |
[[Category:Riel's heuristics]] | [[Category:Riel's heuristics]] | ||
| + | [[Category:RuleAutomation]] | ||
Latest revision as of 03:10, 25 November 2010
- Users of a class must be dependent on its public interface, but a class should not be dependent on its users. --Riel's Heuristic 2.2, Arthur Riel 1996
This heuristic encourages reusability of classes. If a class needs to use another class, obviously it depends on that class. However the dependency relationship should only go one way - the user of the class depends on the class, but the class does not depend on the user. This allows a class to be reused in a variety of contexts.
For example, consider a Person class which uses a Toaster class. The Person class is dependent on the public interface of the Toaster class. The Toaster class should not be dependent on the Person class, because if it were, the Toaster could not later be reused as part of a smart home (which could tell the Toaster to start toasting automatically) without attaching a Person to the Toaster.
Automatability
This rule can be automated in the same way as the Acyclic dependencies principle, looking for length 2 cycles in the directed graph of class coupling.
