One key abstraction
From CSSEMediaWiki
(Difference between revisions)
JaninaVoigt (Talk | contribs) (→See also) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by MartinvanZijl) |
||
| (4 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | Riel's Heuristic | + | :''A class should capture one and only one key abstraction.'' --Riel's Heuristic 2.8, [[Arthur Riel 1996]] |
A class should represent one key abstraction of the domain model, no more and no less. A key abstraction is generally a noun in a requirements statement. If a key abstraction maps to more than one class, the designer may be representing each function of the abstraction as a class. If several key abstractions map to one class, the designer may be creating a centralized system and needs to split the class into several smaller classes. | A class should represent one key abstraction of the domain model, no more and no less. A key abstraction is generally a noun in a requirements statement. If a key abstraction maps to more than one class, the designer may be representing each function of the abstraction as a class. If several key abstractions map to one class, the designer may be creating a centralized system and needs to split the class into several smaller classes. | ||
| − | |||
== See also == | == See also == | ||
| Line 11: | Line 10: | ||
* [[Separation of concerns]] | * [[Separation of concerns]] | ||
* [[Interface segregation principle]] | * [[Interface segregation principle]] | ||
| + | * [[Extract Class]] | ||
| + | * [[Divergent change smell]] | ||
| + | |||
| + | [[Category:Riel's heuristics]] | ||
| + | [[Category:Pages that need examples]] | ||
Latest revision as of 03:11, 25 November 2010
- A class should capture one and only one key abstraction. --Riel's Heuristic 2.8, Arthur Riel 1996
A class should represent one key abstraction of the domain model, no more and no less. A key abstraction is generally a noun in a requirements statement. If a key abstraction maps to more than one class, the designer may be representing each function of the abstraction as a class. If several key abstractions map to one class, the designer may be creating a centralized system and needs to split the class into several smaller classes.
