10 OOAD (Object orientation analysis and design) principles.

1) Open Closed Principle (OCP): -

Code should be open for extension and close for modification.

2) Liskov Substitution Principle (LSP): -

 Every function which operates upon a reference or a pointer to a base class should be able to operate upon derivatives of that base class without knowing it.

3) Dependency Inversion Principle (DIP): -

 High level modules should not depend upon low level modules. Both should depend upon abstraction. Abstraction should not depend upon details. Details should depend upon abstraction.

4) Interface segregation Principle (ISP): - 

Client should not be forced to depend upon interfaces that they do not use. Many client specific interface are better then one general purpose interface.

5) Release Reuse Equivalency Principle (REP): -

 The granule of reuse is the granule of release. Users will be unwilling to use the element if they need or forced to upgrade every time author changes it.

6) Common Closure Principle (CCP): - 

Classes those changes together belong together. The more packages that change in any given release, the greater the work to rebuild, test and deploy the release. So they should be grouped together.

7) Common Reuse Principle (CRP): - 

Classes that are not used together should not be grouped together. A dependency upon a package is a dependency upon everything in the package. When a package changes, and its release number is bumped , all clients of that package must verify that they work with the new package even if nothing they used within package actually changed.

8) Acyclic Dependencies Principle (ADP): - 

The dependencies between packages must not form cycles.

9) Stable Dependencies Principle (SDP): - 

Depend in the direction of stability. A package with lots of incoming dependencies is very stable because it requires a great deal of work to reconcile any changes with all the dependent packages.

10) Stable Abstraction Principle (SAP): -

 Stable packages should be abstract packages. The SAP I sjust a restatement of the DIP. It states that the packages that are most dependent upon (i.e. stable) should also be most abstract.

Resource Link: http://sabbirahamed.blogspot.com/