Design maxims

Revision as of 03:57, 29 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
• 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
• KenAuer1995:
  • DefineClassesByBehaviorNotStatePattern.
  • ImplementBehaviorWithAbstractStatePattern.
  • IdentifyMessageLayersPattern.
  • DeferIdentificationOfStateVariablesPattern.
  • EncapsulateConcreteStatePattern.
  • UseLazyInitializationPattern.
  • DefineDefaultValuesViaExplicitProtocolPattern.
• AlanDavis1995:
• Code smells:
  • Duplicate code smell
  • Long method smell
  • Large class smell
  • Long parameter list smell
  • Divergent change smell
  • Shotgun surgery smell
  • Feature envy smell
  • Data clumps smell
  • Switch statement smell