Design Principles
The Open/Closed Principle
Software entities (classes, modules, etc) should be open for extension, but closed for modification
The Liskov Substitution Principle
Liskov’s notion of “subtype” is based on the notion of substitutability; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness). ie Derived classes must be usable through the base class interface without the need for the user to know the difference
The Dependency Inversion Principle
High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
The Interface Segregation Principle
The dependency of one class to another one should depend on the smallest possible interface. Many client specific interfaces are better than one general purpose interface/
The Reuse/Release Equivalency Principle
The unit of reuse is the unit of release. Effective reuse requires tracking of releases from a change control system. The package is the effective unit of reuse and release.
The Common Closure Principle
Classes that change together, belong together.
Common Reuse Principle
The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all
The Acyclic Dependencies Principle
The dependency structure between packages must be a Directed Acyclic Graph (DAG).
The Stable Dependencies Principle
Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender.
The Stable Abstractions Principle
The more stable a class category is, the more it must consist of abstract classes. A completely stable category should consist of nothing but abstract classes.
Published: