Design maxims
From CSSEMediaWiki
(Difference between revisions)
Line 59: | Line 59: | ||
'''Clumps of maxims''' | '''Clumps of maxims''' | ||
− | + | * JohnsonAndFootesHeuristics: | |
* RecursionIntroduction. | * RecursionIntroduction. | ||
* EliminateCaseAnalysis. | * EliminateCaseAnalysis. |
Revision as of 00:57, 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