Skip to main content

SOLID - Principles of Object Oriented Class Design

The theory of SOLID principles was introduced by Martin in his 2000 paper "Design Principles and Design Patterns". The SOLID acronym was introduced later by Michael Feathers.

1. Single responsibility principle
A class should have only one reason to change

Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to be changed (i.e. rewritten).

"When designing our classes, we should aim to put related features together, so whenever they tend to change they change for the same reason. And we should try to separate features if they will change for different reasons." - Steve Fenton

2. Open-Closed Principle
A module should be open for extension but closed for modification.

Of all the principles of object oriented design, this is the most important.

It means simply this: We should write our modules so that they can be extended, without requiring them to be modified. In other words, we want to be able to change what the modules do, without changing the source code of the modules.

3. Liskov Substitution Principle
Subclasses should be substitutable for their base classes

This principle was coined by Barbar Liskov in her work regarding data abstraction and type theory. It also derives from the concept of Design by Contract (DBC) by Bertrand Meyer

Derived classes should be substitutable for their base classes. That is, a user of a base class should continue to function properly if a derivative of that base class is passed to it.

4. Interface Segregation Principle
Many client specific interfaces are better than one general purpose interface

The essence of the principle is quite simple. If you have a class that has several clients, rather than loading the class with all the methods that the clients need, create specific interfaces for each client and multiply inherit them into the class.

5. Dependency Inversion Principle
Depend upon Abstractions. Do not depend upon concretions

Dependency Inversion is the strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes. This principle is the enabling force behind component design, COM, CORBA, EJB, etc.