Design maxims
From CSSEMediaWiki
(Difference between revisions)
| Line 9: | Line 9: | ||
* [[Acyclic dependencies principle]] | * [[Acyclic dependencies principle]] | ||
* [[Avoid downcasting]] | * [[Avoid downcasting]] | ||
| − | * | + | * [[Avoid equals]] |
| − | * | + | * [[Avoid inheritance for implementation]] |
| − | * | + | * [[Avoid side effects]] |
| − | * | + | * [[Behavioral completeness]] |
| − | * | + | * [[Big design up front]] |
| − | * | + | * [[Command query separation]] |
| − | * | + | * [[Common closure principle]] |
| − | * | + | * [[Common reuse principle]] |
| − | * | + | * [[Coupling and cohesion]] |
| − | * | + | * [[Dependency inversion principle]] |
| − | * | + | * [[Design by contract]] |
| − | * | + | * [[Don't burn your base class]] |
| − | * | + | * [[Don't expose mutable attributes]] |
* [[Don't repeat yourself]] | * [[Don't repeat yourself]] | ||
| − | * | + | * [[Do the simplest thing that could possibly work]] |
| − | * | + | * [[Encapsulate that which varies]] |
| − | * | + | * [[Encapsulation is hierarchical]] |
| − | * | + | * [[Fat interfaces]] |
| − | * | + | * [[Favor composition over inheritance]] |
| − | * | + | * [[Getters and setters]] |
| − | * | + | * [[Goto considered harmful]] |
| − | * | + | * [[Hide your decisions]] |
| − | * | + | * [[Impedance mismatch]] |
| − | * | + | * [[Information hiding]] |
| − | * | + | * [[Interface segregation principle]] |
| − | * | + | * [[Keep accessors and mutators separate]] |
| − | * | + | * [[Keep it simple]] |
| − | * | + | * [[Law of demeter]] |
| − | * | + | * [[Liskov substitution principle]] |
| − | * | + | * [[Model the real world]] |
| − | * | + | * [[Named constants]] |
| − | * | + | * [[No concrete base classes]] |
| − | * | + | * [[No silver bullet]] |
| − | * | + | * [[One responsibility rule]] |
| − | * | + | * [[Open closed principle]] |
| − | * | + | * [[Once and only once]] |
| − | * | + | * [[Premature optimization]] |
| − | * | + | * [[Program to the interface not the implementation]] |
| − | * | + | * [[Reuse release equivalence principle]] |
| − | * | + | * [[Single responsibility principle]] |
* SeparationOfConcerns | * SeparationOfConcerns | ||
* SingleChoicePrinciple | * SingleChoicePrinciple | ||
Revision as of 01:09, 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
- Avoid equals
- Avoid inheritance for implementation
- Avoid side effects
- Behavioral completeness
- Big design up front
- Command query separation
- Common closure principle
- Common reuse principle
- Coupling and cohesion
- Dependency inversion principle
- Design by contract
- Don't burn your base class
- Don't expose mutable attributes
- Don't repeat yourself
- Do the simplest thing that could possibly work
- Encapsulate that which varies
- Encapsulation is hierarchical
- Fat interfaces
- Favor composition over inheritance
- Getters and setters
- Goto considered harmful
- Hide your decisions
- Impedance mismatch
- Information hiding
- Interface segregation principle
- Keep accessors and mutators separate
- Keep it simple
- Law of demeter
- Liskov substitution principle
- Model the real world
- Named constants
- No concrete base classes
- No silver bullet
- One responsibility rule
- Open closed principle
- Once and only once
- Premature optimization
- Program to the interface not the implementation
- Reuse release equivalence principle
- Single responsibility principle
- SeparationOfConcerns
- SingleChoicePrinciple
- SoftwareCrisis
- SoftwareReuse
- StableAbstractionsPrinciple
- StableDependenciesPrinciple
- Tell, Don't Ask
- 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
