Maxim Hierarchy
From CSSEMediaWiki
(Difference between revisions)
m (→Avoid unnecessary complexity) |
|||
Line 42: | Line 42: | ||
* [[Command query separation]] | * [[Command query separation]] | ||
=== Avoid unnecessary complexity === | === Avoid unnecessary complexity === | ||
+ | ==== Reuse ==== | ||
+ | * [[Software reuse]] | ||
+ | * [[Once and only once]] | ||
* [[Don't repeat yourself]] | * [[Don't repeat yourself]] | ||
+ | * [[Reuse release equivalence principle]] | ||
+ | ==== Do only what is necessary ==== | ||
* [[Do the simplest thing that could possibly work]] | * [[Do the simplest thing that could possibly work]] | ||
* [[You ain't gonna need it]] | * [[You ain't gonna need it]] | ||
− | * [[ | + | * [[Premature optimization]] |
* [[Keep it simple]] | * [[Keep it simple]] | ||
+ | * [[Establishing priorities]] | ||
+ | ==== Readable Code is Good Code ==== | ||
* [[Named constants]] | * [[Named constants]] | ||
* [[Goto considered harmful]] | * [[Goto considered harmful]] | ||
+ | ==== Group Stuff To Reduce Complexity ==== | ||
* [[Common closure principle]] | * [[Common closure principle]] | ||
− | |||
− | |||
− | |||
− | |||
* [[Single choice principle]] | * [[Single choice principle]] | ||
− | * [[ | + | |
+ | * [[Keep accessors and mutators separate]] | ||
* [[Design by contract]] - The placement of this maxim is difficult... | * [[Design by contract]] - The placement of this maxim is difficult... | ||
+ | |||
=== Minimise connections === | === Minimise connections === | ||
* [[Acyclic dependencies principle]] | * [[Acyclic dependencies principle]] |
Revision as of 10:09, 27 September 2009
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 - Could be Hide Stuff
- Encapsulation is hierarchical - Could be Hide Stuff
- Encapsulation boundary - Could be Hide Stuff
- Interface segregation principle
- One responsibility rule
- Stable dependencies principle - ?
Hide Stuff
- Fat interfaces
- Hide your decisions
- Information hiding
- Tell, Don't Ask
- Don't expose mutable attributes
- Program to the interface not the implementation
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
- No concrete base classes
- Stable abstractions principle
- Open closed principle - ?
Method Level
Avoid unnecessary complexity
Reuse
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
- Keep accessors and mutators separate
- Design by contract - The placement of this maxim is difficult...
Minimise connections
- Acyclic dependencies principle
- Coupling and cohesion
- Impedance mismatch
- Getters and setters
- Law of Demeter
Process & Organisation
All the maxims related to the development processes and management of the development team.