*Bertrand Meyer* formulated the most important principle of object-oriented design - **The Open Closed Principle (OCP)**:
> A module should be open for extension but closed for modification.
**The Open Closed Principle** defines the purpose of object-oriented design (**What**) — We want to be able to change the behavior of modules without changing *the source code* of the modules.
----------
One of the formulations of **The Dependency Inversion Principle (DIP)** by *Robert Martin* (it seems to me the most clear):
> Depend upon Abstractions. Do not depend upon concretions.
If **The Open Closed Principle** determines the goal (**What**), then **The Dependency Inversion Principle** determines the mechanism (**How**) — dependency should target an interface, or an abstract class (should not target a concrete class).
----------
The main reasons for using **The Dependency Inversion Principle** include:
1. The concreate changes more often than the abstract (changing the interface changes the implementation, changing the concrete class does not always change the implementation). Thus, by applying **The Dependency Inversion Principle** you get rid of the need to depend on volatile modules.
2. Dependencies on abstractions represent points where functionality can be extended without changing their source code.
----------
By applying the principle you get the benefits described above regardless of the place of application (layer).
*Bertrand Meyer* formulated the most important principle of object-oriented design - **The Open Closed Principle (OCP)**:
> A module should be open for extension but closed for modification.
**The Open Closed Principle** defines the purpose of object-oriented design (**What**) — We want to be able to change the behavior of modules without changing the source code of the modules.
----------
One of the formulations of **The Dependency Inversion Principle (DIP)** by *Robert Martin* (it seems to me the most clear):
> Depend upon Abstractions. Do not depend upon concretions.
If **The Open Closed Principle** determines the goal (**What**), then **The Dependency Inversion Principle** determines the mechanism (**How**) — dependency should target an interface, or an abstract class (should not target a concrete class).
----------
The main reasons for using **The Dependency Inversion Principle** include:
1. The concreate changes more often than the abstract (changing the interface changes the implementation, changing the concrete class does not always change the implementation). Thus, by applying **The Dependency Inversion Principle** you get rid of the need to depend on volatile modules.
2. Dependencies on abstractions represent points where functionality can be extended without changing their source code.
