Maxim Hierarchy
From CSSEMediaWiki
Revision as of 09:49, 27 September 2009 by Matthew Harward (Talk | contribs)
This is one attempt to categorise maxims.
Contents |
Design & implementation
All those maxims related to the system itself.
Separate and group system parts rationally
Class & Package Level
This is a rather large block... are there any overarching rules that can group these components...
Data & Behaviour
- Avoid downcasting
- Common reuse principle
- Model the real world
- Avoid equals
- Behavioral completeness
- Single responsibility principle
- Separation of concerns
- Dependency injection
- Encapsulate that which varies
- Encapsulation is hierarchical
- Encapsulation boundary
Hide Stuff
- Fat interfaces
- Hide your decisions
- Information hiding
- Tell, Don't Ask
- Don't expose mutable attributes
Inheritance
- Dependency inversion principle
- Favor composition over inheritance
- Avoid inheritance for implementation
- Don't burn your base class
- Law of leaky abstractions
- Liskov substitution principle
Method Level
Avoid unnecessary complexity
- Don't repeat yourself
- Do the simplest thing that could possibly work
- You ain't gonna need it
- Software reuse
- Keep it simple
- Named constants
- Goto considered harmful
- Common closure principle
- Establishing priorities
- Design by contract - The placement of this maxim is difficult
Minimise connections
Process & Organisation
All the maxims related to the development processes and management of the development team.
OO Developers are not perfect
Unsorted
All those maxims that have not been applied to a category...
- Interface segregation principle
- Keep accessors and mutators separate
- Law of Demeter
- No concrete base classes
- No silver bullet
- One responsibility rule
- Open closed principle
- Once and only once
- Premature optimization
- Program to the interface not the implementation
- Reuse release equivalence principle
- Single choice principle
- Stable abstractions principle
- Stable dependencies principle