Principles of OOD

[oberstdan]

Principles of Object Oriented Desing

There are five principles of class design (aka SOLID):

(SRP) The SingleResponsibilityPrinciple

• Each responsibility should be a separate class, because each responsibility is an axis of change.
• A class should have one, and only one, reason to change.
• If a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change.

(OCP) The OpenClosedPrinciple

• Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. (http://www.objectmentor.com/resources/articles/ocp.pdf)
• BertrandMeyer first coined it in the first edition of ObjectOrientedSoftwareConstruction as follows: A class should be open for extension, but closed for modification.
• In other words, (in an ideal world...) you should never need to change existing code or classes: All new functionality can be added by adding new subclasses or methods, or by reusing existing code through delegation. This prevents you from introducing new bugs in existing code. If you never change it, you can't break it. It also prevents you from fixing existing bugs in existing code, if taken to the extreme.

(LSP) The LiskovSubstitutionPrinciple
(ISP) The InterfaceSegregationPrinciple
(DIP) The DependencyInversionPrinciple

There are three principles of package cohesion
(REP) The ReuseReleaseEquivalencePrinciple
(CCP) The CommonClosurePrinciple
(CRP) The CommonReusePrinciple

There are three principles of package coupling
(ADP) The AcyclicDependenciesPrinciple
(SDP) The StableDependenciesPrinciple
(SAP) The StableAbstractionsPrinciple

http://lostechies.com/seanchambers/2008/03/15/ptom-single-responsibility-principle/
http://lostechies.com/joeocampo/2008/03/21/ptom-the-open-closed-principle/
http://lostechies.com/jimmybogard/2008/03/31/ptom-the-dependency-inversion-principle/