Design maxims
From CSSEMediaWiki
(Difference between revisions)
Line 22: | Line 22: | ||
* DontBurnYourBaseClass | * DontBurnYourBaseClass | ||
* DontExposeMutableAttributes | * DontExposeMutableAttributes | ||
− | * | + | * [[Dont repeat yourself]] |
* DoTheSimplestThingThatCouldPossiblyWork | * DoTheSimplestThingThatCouldPossiblyWork | ||
* EncapsulateThatWhichVaries | * EncapsulateThatWhichVaries |
Revision as of 00:49, 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
- AvoidDowncasting
- AvoidEquals
- AvoidInheritanceForImplementation
- AvoidSideEffects
- BehavioralCompleteness
- BigDesignUpFront
- CommandQuerySeparation
- CommonClosurePrinciple
- CommonReusePrinciple
- CouplingAndCohesion
- DependencyInversionPrinciple
- DesignByContract
- DontBurnYourBaseClass
- DontExposeMutableAttributes
- Dont 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