Design maxims
From CSSEMediaWiki
(Difference between revisions)
Line 7: | Line 7: | ||
=== Maxims === | === Maxims === | ||
− | * | + | * [[Acyclic dependencies principle]] |
* AvoidDowncasting | * AvoidDowncasting | ||
* AvoidEquals | * AvoidEquals |
Revision as of 03:15, 23 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