Principles of Object Oriented Design

Intro

Here is a list of main principles of Object Oriented Design (OOD) with short description of them. I’ll provide detailed descriptions for some of the principles in later posts.
OOD principles can be divided into two groups. The first group well known and named SOLID (has 5 principles) and describes class design.
The second group (6 principles) is related to the packaging of the application. Principles from these group describe how package and component design helps us to organize large application into packages or components.

OOD principles help to eleminate the following bad smells of application design:

• Rigidity. The design is difficult to change.
• Fragility. The design is easy to break.
• Immobility. The design is difficult to reuse.
• Viscosity. It is difficult to do the right thing.
• Needless complexity. Overdesign.
• Needless repetition. Excessive use of Copy/Paste (or Mouse abuse).
• Opacity. Disorganized expression.

SOLID

SOLID is acronym for first 5 principles of object-oriented programming and design named by Robert C. Martin. SOLID describes classes organization and its relationships. These principles are:

• Single Responsibility Principle (SRP) - A class should have only one reason to change.
• Open/Closed Principle (OCP) - Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
• Liskov Substitution Principle (LSP) - Subtypes must be substitutable for their base types.
• Interface Segregation Principle (ISP) - Clients should not be forced to depend on methods they do not use. Interfaces belongs to the clients, but not to hierarchy
• Dependency-Inversion Principle (DIP) - High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

Principles of Package and Component Design

Principles of package and component design help to organize large application into packages or components. These principles describe how to manage the contents and relationships between components.

Principles of package and component design can be divided into to groups:

• principles of package cohesion
• principles package coupling

Principles of package cohesion

These group contains 3 principles which help us to allocate classes to packages:

• Reuse/Release Equivalence Principle (REP) - The granule of reuse is the granule of release.
• Common Reuse Principle (CRP) - The classes in a component are reused together. If you reuse one of the classes in a component, you reuse them all.
• Common Closure Principle (CCP) - The classes in a component should be closed together against the same kinds of changes. A change that affects a component affects all the classes in that component and no other components.

Principles of package coupling

These group also contains 3 principles which help us to determine how packages should be interrelated (connected):

• Acyclic Dependencies Principle (ADP) - Allow no cycles in the component dependency graph
• Stable-Dependencies Principle (SDP) - Depend in the direction of stability.
• Stable-Abstractions Principle (SAP) - A component should be as abstract as it is stable.

Instead of conclusion

Provided principles above are just recommendations for keeping application design and architecture appropriate as the system grows and evolves over time.

Here’s what Robert C. Martin wrote in his book Agile Principles, Patterns, and Practices in C#:

It would be a mistake to unconditionally conform to a principle just because it is a principle. The principles are there to help us eliminate bad smells. They are not a perfume to be liberally scattered all over the system. Over-conformance to the principles leads to the design smell of needless complexity.