Design maxims
From CSSEMediaWiki
(Difference between revisions)
m (Reverted edits by Ebybymic (Talk); changed back to last version by LukeRobinson) |
|||
| (43 intermediate revisions by 14 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == Object | + | == Object Oriented Design Maxims == |
maxim:: (noun) A general truth or rule of conduct expressed in a sentence. | maxim:: (noun) A general truth or rule of conduct expressed in a sentence. | ||
| − | + | Let's 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 === | === Maxims === | ||
| Line 9: | Line 11: | ||
* [[Acyclic dependencies principle]] | * [[Acyclic dependencies principle]] | ||
* [[Avoid downcasting]] | * [[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]] | * [[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]] |
| − | * | + | * [[Intelligent children pattern]] |
| − | * | + | * [[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. | ||
| + | |||
| + | ===COSC 427's:=== | ||
| + | * [[Make constructors blocking]] | ||
| + | * [[No Peter Pan objects]] | ||
| + | * [[Avoid mixing inputs and outputs]] | ||
| + | |||
| + | === [[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 [[Riel's heuristics|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]] | ||
| + | |||
| + | ===[[Joshua Bloch]]:=== | ||
| + | * [[Joshua Bloch 2006 Bumper Sticker API Design | Bumper Sticker API Design]] | ||
| − | + | == See Also == | |
| − | * | + | * [[Code smells]] |
| − | + | * [[Patterns]] | |
| − | + | * [http://programmer.97things.oreilly.com/wiki/index.php/Edited_Contributions Edited Contributions] - A whole heap of maxims and ideas... | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 03:08, 25 November 2010
Contents |
Object Oriented Design Maxims
maxim:: (noun) A general truth or rule of conduct expressed in a sentence.
Let's 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
- Intelligent children pattern
- 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.
COSC 427's:
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
Joshua Bloch:
See Also
- Code smells
- Patterns
- Edited Contributions - A whole heap of maxims and ideas...
