Design maxims
From CSSEMediaWiki
(Difference between revisions)
m (removing spaces in the list) |
|||
| Line 11: | Line 11: | ||
* AvoidEquals | * AvoidEquals | ||
* AvoidInheritanceForImplementation | * AvoidInheritanceForImplementation | ||
| − | + | * AvoidSideEffects | |
| − | + | * BehavioralCompleteness | |
| − | + | * BigDesignUpFront | |
| − | + | * CommandQuerySeparation | |
| − | + | * CommonClosurePrinciple | |
| − | + | * CommonReusePrinciple | |
| − | + | * CouplingAndCohesion | |
| − | + | * DependencyInversionPrinciple | |
| − | + | * DesignByContract | |
| − | + | * DontBurnYourBaseClass | |
| − | + | * DontExposeMutableAttributes | |
| − | + | * DontRepeatYourself | |
| − | + | * 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''' | '''Clumps of maxims''' | ||
Revision as of 00:36, 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
- DontRepeatYourself
- 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
