Design Principles and Design Patterns

昨天今天看了這篇論文，做了一些重點整理，我覺得這篇文章很值得一看，講了很多OO設計上的Principle跟對應的理由。
The Summary of "Design Principles and Design Patterns"

• Symptoms of Rotting Design
• Rigidity
• Hard to change, every change causes a casade of subsequent changes.
  
• Fragility
• Break in many places every time it is changed.
  
• Immobility
• Inability to reuse software other projects or from parts of the same project.
  
• Viscosity
• When the design preserving methods are harder to employ than the hacks, it is easy to do the wrong thing, but hard to do the right thing.

• Changing Requirements
• Changes that introduce new and unplanned for dependencies will make the design to rot.

• Principles of Object Oriented Class Design
• OCP (The Open Closed Principle)
• A module should be open for extension but close for modification.
  
• We should write out modules so that they can be extended, without requiring them to be modified, in other word, we want to be able to change what the modules do, without changing the source code of the modules.
• Abstraction is the key to the OCP.
• LSP (The Liskov Substitution Principle)
• Subclasses should be substitutable for their base classes.
• DBC (Design by Concept)
• The contract of the base class must be honored by the derived class.
  
• The derived clas is substitutable for its base class if:
• its precondition are no stronger than the base clas method.
• its precondition are no weaker than the base class method.
• LSP violation is hard to detect until it is too late, and the violation of LSP are latent violations of OCP.
  
• DIP (The Dependency Inversion Principle)
• Depend upon Abstractions. Do not depend upon concretions
• DIP states the primary mechanism of OO design
  
• DIP follow OCP directly.
• ISP (The Interface Segregation Principle)
• Many client specific interfaces are better than one general purpos interface.
• Adding new interfaces to existing objecs, rather than changing the existing interface.

• Principles of Package Architecture
• REP (The Release Reuse Equivalency Principle)
• The granule of reuse is the granule of release
• The author must be willing to support and mainitain older version.
  
• CCP (The Common Closure Principle)
• Classes that change together, belong together.
• When we group classes that change together into the same packages then the package impact from release to release will be minimized.
  
• CRP (The Common Reuse Principle)
  
• Classes that aren't reused together should not be grouped together.
• A dependency upon a package is a dependency upon everything within the package. we do not want to depend on usless classes in the package.
• These three principles are mutually exclusive. That is because each principle benifits a differenct group of people.
• The REP and CRP makes life easy for reusers.
• CCP makes life easier for maintainers, bacause every thing would/should change together are in the same package .
• The CCP strives to make packages as larage as possible. The CRP tries to make packages very small.

• The Package Coupling Priniciple
• ADP (The Acyclic Dependencies Principle)
• The depencency between packages must not form cycles.
• Before the new release, they must test that packege work, and they must compile and build it with all the package that it depends upon.
• Breaking a Cycle
• Add new package
• Use DIP and ISP
  
• Inverting the dependency, this is done by adding a new iterface.
  
• SDP (The Stable Dependencies Principle)
• Depend in the direction of stability.
• One sure way to make a software package difficult to change, is to make lot of other software package depend upon it.
• Stability
• Stability is related to the amount of work required to make a change.
• Stability Metrics
• Instability: I=>[0,1]
• Depend upon package whose I metric is lower than yours.
  
• But we desire that portions of our software be instable, because we need flexibility, the SAP could handle it.
• SAP (The Stable Abstractions Principle)
• Stable packages should be abstract packages.
• The highly stable package at the bottom of the dependency network may be very difficult to change, but not have to be difficult to extend.
• The SAP is just a restatement of the DIP, the most depended upon should also be the most abstract.
• The Abstractness Metrics
• Abstractness: A=>[0,1]