Split large classes
From CSSEMediaWiki
(Difference between revisions)
JaninaVoigt (Talk | contribs) |
|||
| Line 1: | Line 1: | ||
A large class generally represents a poor design. A class should represent an abstraction, and the larger the class the more complicated the abstraction. It is likely that any class containing 50 methods is representing several abstractions and should be split up into the separate abstractions. [[Johnson and Foote 1988]] states that "Large classes should be viewed with suspicion and held to be guilty of poor design until proven innocent". | A large class generally represents a poor design. A class should represent an abstraction, and the larger the class the more complicated the abstraction. It is likely that any class containing 50 methods is representing several abstractions and should be split up into the separate abstractions. [[Johnson and Foote 1988]] states that "Large classes should be viewed with suspicion and held to be guilty of poor design until proven innocent". | ||
| + | |||
| + | The main motivation behind this rule is that large classes are much harder to reuse than a collection of small classes. | ||
== See Also == | == See Also == | ||
* [[Large class smell]] | * [[Large class smell]] | ||
| + | * [[Single responsibility principle]] | ||
| + | * [[One key abstraction]] | ||
[[Category: Johnson and Foote's heuristics]] | [[Category: Johnson and Foote's heuristics]] | ||
Latest revision as of 01:14, 20 August 2009
A large class generally represents a poor design. A class should represent an abstraction, and the larger the class the more complicated the abstraction. It is likely that any class containing 50 methods is representing several abstractions and should be split up into the separate abstractions. Johnson and Foote 1988 states that "Large classes should be viewed with suspicion and held to be guilty of poor design until proven innocent".
The main motivation behind this rule is that large classes are much harder to reuse than a collection of small classes.
