Design maxims
From CSSEMediaWiki
(Difference between revisions)
m (Formatting bullets etc) |
m (Adding links etc) |
||
| Line 61: | Line 61: | ||
'''Clumps of maxims''' | '''Clumps of maxims''' | ||
* [[Johnson and Foote's heuristics]]: | * [[Johnson and Foote's heuristics]]: | ||
| − | ** Recursion introduction | + | ** [[Recursion introduction]] |
| − | ** Eliminate case analysis | + | ** [[Eliminate case analysis]] |
| − | ** Reduce the number of arguments | + | ** [[Reduce the number of arguments]] |
| − | ** Reduce the size of methods | + | ** [[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]] |
* BobMartinsPrinciples: | * BobMartinsPrinciples: | ||
** (SRP) The SingleResponsibilityPrinciple | ** (SRP) The SingleResponsibilityPrinciple | ||
Revision as of 02:15, 27 July 2008
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.
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 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
- 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
- Liskov substitution principle
- Model the real world
- Named constants
- 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 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
- 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
- BobMartinsPrinciples:
- (SRP) The SingleResponsibilityPrinciple
- (OCP) The OpenClosedPrinciple
- (LSP) The LiskovSubstitutionPrinciple
- (DIP) The DependencyInversionPrinciple
- (ISP) The InterfaceSegregationPrinciple
- (REP) The ReuseReleaseEquivalencePrinciple
- (CCP) The CommonClosurePrinciple
- (CRP) The CommonReusePrinciple
- (ADP) The AcyclicDependenciesPrinciple
- (SDP) The StableDependenciesPrinciple
- (SAP) The StableAbstractionsPrinciple
- KenAuer1995:
- DefineClassesByBehaviorNotStatePattern.
- ImplementBehaviorWithAbstractStatePattern.
- IdentifyMessageLayersPattern.
- DeferIdentificationOfStateVariablesPattern.
- EncapsulateConcreteStatePattern.
- UseLazyInitializationPattern.
- DefineDefaultValuesViaExplicitProtocolPattern.
- AlanDavis1995:
- Code smells
