Design maxims

Revision as of 02:05, 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.
  • ClassHierarchiesShouldBeDeepAndNarrow.
  • TheTopOfTheClassHierarchyShouldBeAbstract.
  • MinimizeAccessesToVariables.
  • SubclassesShouldBeSpecializations.
  • SplitLargeClasses.
  • FactorImplementationDifferencesIntoSubcomponents.
  • SeparateMethodsThatDoNotCommunicate.
  • SendMessagesToComponentsInsteadOfToSelf.
  • ReduceImplicitParameterPassing
• RielsHeuristics:
• 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