Design maxims

Revision as of 13:17, 8 October 2009

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

See Also

• Code smells
• Patterns
• Edited Contributions - A whole heap of maxims and ideas...