Design maxims
From CSSEMediaWiki
(Difference between revisions)
BenMcDonald (Talk | contribs) |
|||
| Line 48: | Line 48: | ||
* [[No concrete base classes]] | * [[No concrete base classes]] | ||
* [[No silver bullet]] | * [[No silver bullet]] | ||
| + | * [[Once and only once]] | ||
* [[One responsibility rule]] | * [[One responsibility rule]] | ||
* [[Open closed principle]] | * [[Open closed principle]] | ||
| − | * [[ | + | * [[Option-operand separation]] |
* [[Premature optimization]] | * [[Premature optimization]] | ||
* [[Program to the interface not the implementation]] | * [[Program to the interface not the implementation]] | ||
Revision as of 10:06, 5 October 2009
Contents |
Object Oriented Design Maxims
maxim:: (noun) A general truth or rule of conduct expressed in a sentence.
Lets use the term maxim to mean all the rules, laws, guidelines, principles, heuristics, strategies, patterns and idioms that are named by a standard phrase.
Maxim Hierarchy - An attempt at creating a hierarchy of maxims can be found here.
Maxims
- Acyclic dependencies principle
- Avoid downcasting
- Avoid equals
- Avoid inheritance for implementation
- Avoid side effects
- Behavioral completeness
- Big design up front
- Command query separation
- Common closure principle
- Common reuse principle
- Coupling and cohesion
- Dependency injection
- Dependency inversion principle
- Design by contract
- Don't burn your base class
- Don't expose mutable attributes
- Don't repeat yourself
- Do the simplest thing that could possibly work
- Encapsulate that which varies
- Encapsulation is hierarchical
- Encapsulation boundary
- Establishing priorities
- Fat interfaces
- Favor composition over inheritance
- Getters and setters
- Goto considered harmful
- Hide your decisions
- Impedance mismatch
- Information hiding
- Interface segregation principle
- Keep accessors and mutators separate
- Keep it simple
- Law of Demeter
- Law of leaky abstractions
- Liskov substitution principle
- Model the real world
- Named constants
- No concrete base classes
- No silver bullet
- Once and only once
- One responsibility rule
- Open closed principle
- Option-operand separation
- Premature optimization
- Program to the interface not the implementation
- Reuse release equivalence principle
- Single responsibility principle
- Separation of concerns
- Single choice principle
- Software crisis
- Software reuse
- Stable abstractions principle
- Stable dependencies principle
- Tell, Don't Ask
- You ain't gonna need it
Clumps of Maxims
These are groups of Maxims, usually gathered by the developer(s) who proposed them.
Johnson and Foote's heuristics:
- Recursion introduction
- Eliminate case analysis
- Reduce the number of arguments
- Reduce the size of methods
- Class hierarchies should be deep and narrow
- The top of the class hierarchy should be abstract
- Minimize accesses to variables
- Subclasses should be specializations
- Split large classes
- Factor implementation differences into subcomponents
- Separate methods that do not communicate
- Send messages to components instead of to self
- Reduce implicit parameter passing
Riel's heuristics
- All of Riel's heuristics can be found here.
Bob Martin's principles:
- (SRP) The Single responsibility principle
- (OCP) The Open/closed principle
- (LSP) The Liskov substitution principle
- (DIP) The Dependency inversion principle
- (ISP) The Interface segregation principle
- (REP) The Reuse release equivalence principle
- (CCP) The Common closure principle
- (CRP) The Common reuse principle
- (ADP) The Acyclic dependencies principle
- (SDP) The Stable dependencies principle
- (SAP) The Stable abstractions principle
Ken Auer 1995:
- Define classes by behavior, not state pattern
- Implement behavior with abstract state pattern
- Identify message layers pattern
- Defer identification of state variables pattern
- Encapsulate concrete state pattern
- Use lazy initialization pattern
- Define default values via explicit protocol pattern
Alan Davis 1995:
To be completed...
William Brown 1998:
- Managing functionality
- Managing performance
- Managing complexity
- Managing change
- Managing IT resources
- Managing technology transfer
