Object-Oriented Design Principles

Printer-friendly versionSend to friend
Open Closed Principle (OCP)
Classes, or other software components, should be open for extension, but closed for modification. I.e., ideally, one should never have to change an existing class, but rather should be able to extend it and re-use it in new contexts. The intention is that one should not have to modify software that is already working and thus potentially introduce bugs. Of course, if the definition of the responsibility which the class represents changes, it may be necessary or appropriate to change the class, but if the essential responsibility which the class represents has not changed, then the class should not change.

Liskov Substitution Principle (LSP)5
If a class X is a subtype of class Y, then any instance of class X should be substitutable in any context in which class Y was expected. In other words, any true subtype is a behavioral substitute for the parent and has at least the same knowledge as the parent.

Interface Segregation Principle (ISP)
The dependency of one class on another should be based on the smallest possible interface. I.e., components of a system should be decoupled to the extent possible and no class should need to know about methods which do not pertain to it. This makes it easier to refactor and change a system. Note, if an interface defines the invariants of a particular concern or subject matter, that is inherently the smallest possible interface for that concern or subject matter. I.e., the issue is less the number of elements in an interface than it is decomposition to intrinsic cohesive concerns in the problem space.

Dependency Inversion Principle (DIP)
High level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. These principles are intended to avoid fragile, rigid, and immobile designs.

Package Cohesion Principles

The next three principles relate to the cohesion of classes within packages, i.e., how does one decide what should be within the package versus what should not.

Reuse Release Equivalence Principle (REP)
The unit of reuse is the unit of release. In order to effectively reuse code, it must be available as a complete black box. Thus, users of the code are shielded from changes to the code and only need to modify their own code when and if they desire to take advantage of new functionality which has been added. It is sometimes called the Black Box Principle.

Common Closure Principle (CEP)
Classes that are tightly coupled with each other should be part of the same package; unless classes are tightly coupled, they should not be part of the same package. While individual classes within a package may not be tightly coupled one to the other, the classes in the package as a whole should be tightly coupled or they should not be a package. This is an extension of the idea of the cohesion within a class and its separation from other classes, but at the package level.

Attachment	Size
OODesignPrinciples_20100123.pdf	78.65 KB