Design maxims

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
Line 8: Line 8:
  
 
* [[Acyclic dependencies principle]]
 
* [[Acyclic dependencies principle]]
* AvoidDowncasting
+
* [[Avoid downcasting]]
 
* AvoidEquals
 
* AvoidEquals
 
* AvoidInheritanceForImplementation
 
* AvoidInheritanceForImplementation
Line 22: Line 22:
 
* DontBurnYourBaseClass
 
* DontBurnYourBaseClass
 
* DontExposeMutableAttributes
 
* DontExposeMutableAttributes
* [[Dont repeat yourself]]
+
* [[Don't repeat yourself]]
 
* DoTheSimplestThingThatCouldPossiblyWork
 
* DoTheSimplestThingThatCouldPossiblyWork
 
* EncapsulateThatWhichVaries
 
* EncapsulateThatWhichVaries

Revision as of 01:01, 24 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
  • AvoidEquals
  • AvoidInheritanceForImplementation
  • AvoidSideEffects
  • BehavioralCompleteness
  • BigDesignUpFront
  • CommandQuerySeparation
  • CommonClosurePrinciple
  • CommonReusePrinciple
  • CouplingAndCohesion
  • DependencyInversionPrinciple
  • DesignByContract
  • DontBurnYourBaseClass
  • DontExposeMutableAttributes
  • Don't repeat yourself
  • DoTheSimplestThingThatCouldPossiblyWork
  • EncapsulateThatWhichVaries
  • EncapsulationIsHierarchical
  • FatInterfaces
  • FavorCompositionOverInheritance
  • GettersAndSetters
  • GotoConsideredHarmful
  • HideYourDecisions
  • ImpedanceMismatch
  • InformationHiding
  • InterfaceSegregationPrinciple
  • KeepAccessorsAndMutatorsSeparate
  • KeepItSimple
  • LawOfDemeter
  • LiskovSubstitutionPrinciple
  • ModelTheRealWorld
  • NamedConstants
  • NoConcreteBaseClasses
  • NoSilverBullet
  • OneResponsibilityRule
  • OpenClosedPrinciple
  • OnceAndOnlyOnce
  • PrematureOptimization
  • ProgramToTheInterfaceNotTheImplementation
  • ReuseReleaseEquivalencePrinciple
  • SingleResponsibilityPrinciple
  • SeparationOfConcerns
  • SingleChoicePrinciple
  • SoftwareCrisis
  • SoftwareReuse
  • StableAbstractionsPrinciple
  • StableDependenciesPrinciple
  • TellDontAsk
  • YouAintGonnaNeedIt

Clumps of maxims

  • JohnsonAndFootesHeuristics:
 * RecursionIntroduction.
 * EliminateCaseAnalysis.
 * ReduceTheNumberOfArguments.
 * ReduceTheSizeOfMethods.
 * 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:
* CodeSmells
Personal tools