SE450: Martin's principles [4/12]

Martin's principles are highlighted in the paper Design Principles and Design Patterns at his website, www.objectmentor.com. This site is an excellent resource on OO programming, XP, and design techniques.

The Open/Closed Principle: Software entities (classes, modules, etc) should be open for extension, but closed for modification. Abstraction is the key to this principle. This is possible through dynamic polymorphism.

The Liskov Substitution Principle: Derived classes must be usable through the base class interface without the need for the user to know the difference. This implies:

• if you write a subclass, you should never have to rewrite client code that works with the superclass.
• If an instance of a class is expected, an instance of the subclass should be substitutable.
• A subclass inherits the invariant (DBC), and can only strengthen it
• A precondition of an inherited method can be only weakened
• A postcondition can be only strengthened.

Violations of LSP are latent violations of OCP

The Dependency Inversion Principle: Details should depend upon abstractions. Abstractions should not depend upon details (concretions). Dependencies between classes should target interfaces or abstract classes. This provides flexibility to the design. This keeps you from depending on volatile modules.

The Interface Segregation Principle: Many client specific interfaces are better than one general purpose interface

The Reuse/Release Equivalency Principle: The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused.

The Common Closure Principle: Classes that change together, belong together.

The Common Reuse Principle: Classes that aren't reused together should not be grouped together.

The Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph. There can be no cycles.

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.