A degree of importance that grants a design decision may called Prinipal. When we will design any software based on OO that time we should follow some principals.
If we follow that principal then we will get some benifits. Ex
1. Software will be scalable.
2. Easily extendable.
3. Maintance phase will be very simple.
4. Programming code is easily readable.
5. Easy production code changable.
6. Easily backword compatable.
7. Easily re-usable.
and many more.
Principals are separated by Class Desing Principal and Package Design Principal
Class Design Principles are:
1. Single Responsibility Principal (SRP) :
================================
A class should have only one responsibility. The difination of responsibility is "a reason for change". If any class has more then one responsibility then threre will be more coupled. Change of one responsibility may impact others.
2. Open Close Principle(OCP):
==========================
Able to extend class behavior without modifing existing begaviour. That means we should desing class or component that shold never change. If requirement change then we extend the behaviour of such component/class by adding new code, not the tested old code.
3. Liskov Substitution Principle(LSP):
==============================
Also known as "Design by Contract". Derived class must be substitutable for their base classes. Means derived class must be usable through the base class interface without the need for the user to know the difference.
4. Dependency Inversion Principle(DIP):
==================================
Depends on abstraction not concretion. Another way we can express like Details should depend upon abstraction, Abstraction should not depends on Details. Main befinit of it is, it creates decoupling between classes. For that reason if we change detail class it should not affect existing class that are using that detail class. Currently many framework/pattern created for dependency inject. Microsoft Uniti Application block, ObjectBuilder etc are examples. Microsoft Composit Application Block (Smart Client Software Factory/ Web Client Software factory/Web service software factory) is havily depends on that principal.
5. Interface Segregation Principle(ISP):
================================
Create Interface that are client specific. Client should not be forced to depends upon interfaces that they dont use. The interface which contain extra methods which are not related to all clients is called fat interface. It is preferable to remove fat interface and create many small interfaces based on groups of methods.
Package Design Principles are:
1. Release re-use Equivalency Principle(REP) :
=====================================
A reusable element can be class, component cannot be reused unless it is managed by a released system. One criteria for grouping classes into packages is reuse, Packages are unit of release, also unit of reuse. So we should group reusable classes into packages and deploy to the clients. This package should be under any version no. Clients are fully independent and has full knowledge to use or used package version.
2. Common Closure Principle(CCP):
===============================
Classes that are change together are packaged together. If two classes are tightly bound(phisically/conceptually), they almost change together, then they belongs to the same package. It minimize the workload to releasing, revalidating, redistributing software and impact minimum from release to release.
3. Common Reuse Principle(CRP):
===============================
Classes that are not reused together should not be group together. Depency of a package is dependency of everything within that package. When package changed, new release no will be assigned and client musht varify they work with new package even if nothing they use within a package that changed.
4. Acyclic Dependency Principle(ADP):
================================
Dependency between package must not form of cycles. If found any cycle then it will be breked. For breking cycle We can use Dependency Inversion Principle.
5. Stable Dependency Principle(SDP):
=================================
Depend in the direction of stability. Means package should stable on that package that are more stable that it is. All packages are not stable of any software. If so then the software is difficult to change. So comparatively less stable package should depends on more stable package.
6. Stable Abstraction Principle(SAP):
===============================
Stable package may be abstract. Instable package should be concrete. Means its stability does not prevent it from being extended and instability allows the concreate code within it to be easily changed.
