Simplicity, Clarity, Maintainability Abstraction Decomposition

Simplicity, Clarity, MaintainabilitySimplicity and clarity are fundamental to managing the complexity of large systems.Start with a good base architecture. Keep the design as simple as possible. Refactor as needed tosupport new features as they are added.Good designs hold up well under change (i.e., maintenance) as new features are added.Simplicity and clarity enhance maintainability.Design Smells: Lazy Class, Speculative Generality, Temporary Field, Middle ManAbstractionPrecise data type definition with Design by ContractGood naming (packages, classes, methods, variables, files, directories, …)Encapsulation / Information HidingDesign Smells: Message Chains, Inappropriate IntimacyEffective encapsulation of data structuresData integrity enforcementError handlingEnable/disable supportDesign Smells: Primitive Obsession, Feature Envy, Data Clumps, Alternative classes with differentinterfaces, Data ClassDecompositionLevels of design (Sub-system, Package, Class/Interface, Method)Hypo and Hyper DecompositionSize/Length metricsComplexity metricsDesign Smells: Long Method, Large Class, Comments

Good Algorithm and Data Structure SelectionUsing the principles learned in CS 235 and 312 to select appropriate algorithms and data structures isessential to runtime efficiency. No amount of abstraction, decomposition, etc. will compensate for poorchoices in this area.Don’t Repeat Yourself / Avoid Code DuplicationPatterns: Template Method, Builder, VisitorDesign Smells: Duplicated Code, Switch Statements, Parallel Inheritance HierarchiesSingle Responsibility Principle / Cohesion / Separation of ConcernsEvery class and method should have a single responsibility. A class should represent one well-definedconcept, and only contain functionality that is highly-related to that concept. A method should do onething and do it well. Classes and methods should have good names that describe their oneresponsibility.Separate dissimilar concepts in your code. This allows you to change one without affecting the other.Patterns: Visitor, Builder, DecoratorDesign Smells: Divergent ChangeIsolated Change PrincipleIdeally, the implementation of a responsibility should be isolated to a single place in the code. This way,if something about a responsibility changes, there will be only one place in the code that needs to bechanged.Patterns: Template Method, Builder, Visitor, DAODesign Smells: Shotgun SurgeryOpen-Closed PrincipleSoftware entities should be open for extension, but closed for modificationComposition: Depend on abstractions, not on concretionsInheritance: Override polymorphic methodsPatterns: Strategy, Plug-InPatterns: Template Method, Factory Method

Dependency Inversion PrincipleI need to call you, but I don’t want to depend on your interface (i.e., API)Caller defines abstract interface through which the call occursImportant Application: If a subsystem/layer needs to notify callers of events (i.e., callbacks), thesubsystem/layer defines the abstract interface through which the notification occursPatterns: Observer, CommandCode ReusePrefer Object Composition over Class Inheritance (flexibility, control over which features are exposedlower coupling)Patterns: Adapter, Decorator, Strategy, Template Method, Factory MethodDesign for TestabilitySpecific features can be added to a design to make the system easier to test.