Saturday, July 16, 2011

Design Principles and Design Patterns

Object Oriented Class Design

  • Open-Closed Principle (OCP)
    • We should write our modules so that they can be extended, without requiring them to be modified.
    • Techniques:
      • Dynamic polymorphism
      • Static polymorphism (templates or generics)
  • Liskov Substitution Principle (LSP)
    • Derived classes should be substitutable for their base classes.
    • Derives from concept of Design by Contract
    • In terms of contracts, a derived class is substitutable for its base class if:
      • Its preconditions are not stronger than the base class method.
      • Its postconditions are no weaker than the base class method.
      • (In other words, derived methods should expect no more and provide no less)
    • There are subtleties: canonical example is the Circle/Ellipse dilemma
  • Dependency Inversion Principle (DIP)
    • Strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes.
    • Motivation behind DIP is to prevent you from depending upon volatile modules. The DIP makes the assumption that anything concrete is volatile.
    • Object creation: abstract factory
  • Interface Segregation Principle (ISP)
    • Many client specific interfaces are better than one general purpose interface
Package Architecture
  • Release Reuse Equivalency Principle (REP)
    • One criterion for grouping classes into packages is reuse
  • Common Closure Principle (CCP)
    • Group together classes that we think will change together
  • Common Reuse Principle (CRP)
    • Classes that aren't reused together should not be grouped together
    • "Changes to a class that I don't care about will still force a new release of the package, and still cause me to go through the effort of upgrading and revalidating."
  • Acyclic Dependencies Principle (ADP)
    • The dependencies between packages must not form cycles.
    • Breaking cycles
      • Creating a new package
      • Make use of DIP and ISP
  • Stable Dependencies Principle (SDP)
    • Depend in the direction of stability
    • Stability is related to the amount of work required to make a change
    • Should all software be stable? We greatly desire that portions of our software be instable. We want certain modules to be easy to change so that when requirements drift, the design can respond with ease.
  • Stable Abstractions Principle (SAP)
    • Stable packages should be abstract packages
    • The more packages that are hard to change, the less flexible our overall design will be. Highly stable packages at the bottom of the dependency network may be very difficult to change, but according to the OCP they do not have to be difficult to extend!
    • SAP is just a restatement of the DIP - it states the packages that are the most depended upon (i.e. stable) should also be the most abstract
Post a Comment