Maxim Hierarchy
From CSSEMediaWiki
(Difference between revisions)
BenMcDonald (Talk | contribs) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Lukas Korsika) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 10: | Line 10: | ||
* [[Single responsibility principle]] | * [[Single responsibility principle]] | ||
* [[Separation of concerns]] | * [[Separation of concerns]] | ||
| − | + | ||
==== Object Behaviour ==== | ==== Object Behaviour ==== | ||
* [[Avoid downcasting]] | * [[Avoid downcasting]] | ||
| Line 17: | Line 17: | ||
* [[Encapsulate that which varies]] | * [[Encapsulate that which varies]] | ||
* [[Encapsulation is hierarchical]] | * [[Encapsulation is hierarchical]] | ||
| + | * [[Option-operand separation]] | ||
* [[Dependency inversion principle]] | * [[Dependency inversion principle]] | ||
* [[Interface segregation principle]] | * [[Interface segregation principle]] | ||
Latest revision as of 03:08, 25 November 2010
This is an attempt to categorise maxims.
Contents |
Design & Implementation
All those maxims related to the system itself.
Separate and group system parts rationally
Defining the objects
- Encapsulation boundary
- Model the real world
- Behavioral completeness
- Single responsibility principle
- Separation of concerns
Object Behaviour
Object Interface
- Encapsulate that which varies
- Encapsulation is hierarchical
- Option-operand separation
- Dependency inversion principle
- Interface segregation principle
- Fat interfaces
- Hide your decisions
- Information hiding
- Tell, Don't Ask
- Program to the interface not the implementation
Inheritance
- Favor composition over inheritance
- Avoid inheritance for implementation
- Don't burn your base class
- Law of leaky abstractions
- Liskov substitution principle
- No concrete base classes
- Stable abstractions principle
- Open closed principle - ?
- Design by contract
Object Mutability
- Don't expose mutable attributes
- Getters and setters
- Keep accessors and mutators separate
- Command query separation
- Avoid side effects
Avoid unnecessary complexity
Reuse
- Common reuse principle
- Software reuse
- Once and only once
- Don't repeat yourself
- Reuse release equivalence principle
Do only what is necessary
- Do the simplest thing that could possibly work
- You ain't gonna need it
- Premature optimization
- Keep it simple
- Establishing priorities
Readable Code is Good Code
Group Stuff To Reduce Complexity
Dependencies
- Dependency injection
- Stable dependencies principle
- Acyclic dependencies principle
- Coupling and cohesion
- Impedance mismatch
- Law of Demeter
Process & Organisation
All the maxims related to the development processes and management of the development team.
