Principles of object oriented design

Автор: PP

(1) Class design

•SRP – Single Responsibility Principle
Each responsibility should be a separate class.
•OCP – Open Closed Principle
Class should be open for extension, but closed for modification.
•LSP – Liskov Substitution Principle
An instance of a derived should be able to replace any instance of its superclass.
•Design by contract
When redefining a method in a derivate class, you may only replace its precondition by a weaker one, and its post condition by a stronger one.
•DIP – Dependency Inversion Principle
A. High level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.
•ISP – Interface Segregation Principle
The dependency of one class to another one should depend on the smallest possible interface. (Clients should not be forced to depend upon interfaces that they do not use).

(2) Package cohesion & coupling[/b]

•REP – Reuse-Release Equivalence Principle
The granule of reuse is the granule of release. Only components that are released through a tracking system can effectively be reused. This granule is the package.
•CCP – Common Closure Principle
Classes within a released component should share common closure. That is, if one needs to be changed, they all are likely to need to be changed. What affects one, affects all.
•CRP – Common Reuse Principle
Classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.
•ADP – Acyclic Dependencies Principle
The dependency structure between packages must not contain cyclic dependencies.
•SDP – Stable Dependencies Principle
Dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is.
•SAP – Stable Abstraction Principle
Packages that are maximally stable should be maximally abstract. Unstable packages should be concrete. The abstractness of a package should be in proportion to its stability.

(3) Other[/b]

•Information Hiding
If code chunk A doesn't really need to know something about how code chunk B (which it calls) does its job, don't make it know it.
•Single Choice Principle
The exhaustive list of alternatives should live in exactly one place.
•Law Of Demeter

Линки на оригинальные статьи (из которых скомпонована эта):
http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign
http://www.codeguru.com/forum/showthread.php?t=328034

30 июля 2006