Maxim Hierarchy
From CSSEMediaWiki
(Difference between revisions)
(New page: This is one attempt to categorise maxims. == Design & implementation == All those maxims related to the system itself. === Separate and group system parts rationally === ==== Class & Pack...) |
|||
| Line 15: | Line 15: | ||
* [[Separation of concerns]] | * [[Separation of concerns]] | ||
* [[Dependency injection]] | * [[Dependency injection]] | ||
| − | * [[Encapsulate that which varies]] | + | * [[Encapsulate that which varies]] - Could be Hide Stuff |
| − | * [[Encapsulation is hierarchical]] | + | * [[Encapsulation is hierarchical]] - Could be Hide Stuff |
| − | * [[Encapsulation boundary]] | + | * [[Encapsulation boundary]] - Could be Hide Stuff |
| − | + | * [[Interface segregation principle]] | |
| + | * [[One responsibility rule]] | ||
| + | * [[Stable dependencies principle]] - ? | ||
===== Hide Stuff ===== | ===== Hide Stuff ===== | ||
* [[Fat interfaces]] | * [[Fat interfaces]] | ||
| Line 25: | Line 27: | ||
* [[Tell, Don't Ask]] | * [[Tell, Don't Ask]] | ||
* [[Don't expose mutable attributes]] | * [[Don't expose mutable attributes]] | ||
| + | * [[Program to the interface not the implementation]] | ||
===== Inheritance ===== | ===== Inheritance ===== | ||
* [[Dependency inversion principle]] | * [[Dependency inversion principle]] | ||
| Line 32: | Line 35: | ||
* [[Law of leaky abstractions]] | * [[Law of leaky abstractions]] | ||
* [[Liskov substitution principle]] | * [[Liskov substitution principle]] | ||
| + | * [[No concrete base classes]] | ||
| + | * [[Stable abstractions principle]] | ||
| + | * [[Open closed principle]] - ? | ||
==== Method Level ==== | ==== Method Level ==== | ||
* [[Avoid side effects]] | * [[Avoid side effects]] | ||
| Line 45: | Line 51: | ||
* [[Common closure principle]] | * [[Common closure principle]] | ||
* [[Establishing priorities]] | * [[Establishing priorities]] | ||
| − | * [[Design by contract]] - The placement of this maxim is difficult | + | * [[Keep accessors and mutators separate]] |
| + | * [[Once and only once]] | ||
| + | * [[Premature optimization]] | ||
| + | * [[Single choice principle]] | ||
| + | * [[Reuse release equivalence principle]] | ||
| + | * [[Design by contract]] - The placement of this maxim is difficult... | ||
=== Minimise connections === | === Minimise connections === | ||
* [[Acyclic dependencies principle]] | * [[Acyclic dependencies principle]] | ||
| Line 51: | Line 62: | ||
* [[Impedance mismatch]] | * [[Impedance mismatch]] | ||
* [[Getters and setters]] | * [[Getters and setters]] | ||
| + | * [[Law of Demeter]] | ||
== Process & Organisation == | == Process & Organisation == | ||
| Line 57: | Line 69: | ||
* [[Big design up front]] | * [[Big design up front]] | ||
* [[Software crisis]] | * [[Software crisis]] | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
* [[No silver bullet]] | * [[No silver bullet]] | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 10:01, 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
- 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
- Keep accessors and mutators separate
- Once and only once
- Premature optimization
- Single choice principle
- Reuse release equivalence principle
- 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.
