Software Design Principles

Connect with

Learn all aspects of what is Software Design Principles or SOLID design principles? SOLID: SRP, OCP, LSP, ISP, DIP, set of guidelines that solve design requirement.

1. Overview of Software Design Principles

According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:

Rigidity: it is hard to change because every change affects too many other parts of the system.
Fragility: when you make a change, unexpected parts of the system break.
Immobility: Immobility is the inability to reuse software from other projects or from parts of the same project.

2. S.O.L.I.D. Design principles

SOLID is an acronym for the first 5 principles of object-oriented design (OOD) by Robert C. Martin , popularly know as Uncle Bob.

3. S.O.L.I.D Stands for

In the software design principles, SOLID desing principles plays an vital role to design any component in software. These are pretty simple to grasp. Each character has signifiance in SOLID design principles.

S – Single Responsiblity Principle (SRP).
O – Open Closed principle (OCP).
L – Liskov substitution principle (LSP).
I – Interface segregation principle (ISP)
D – Dependency Inversion Principle (DIP)

4. One liner description of SOLID design principles

For learning perspective you must be in your mind one line of each SOLID design principles.

Single Responsibility Principle (SRP) : A class should have one, and only one, reason to change.
Open Closed principle (OCP): You should be able to extend a classes behavior, without modifying it.
Liskov substitution principle (LSP): Derived classes must be substitutable for their base classes, it means objects in a program should be replaceable with instances of their sub-types without altering the correctness of that program.
Interface segregation principle (ISP): Make fine grained interfaces that are client specific.
Dependency Inversion Principle(DI): Depend on abstractions, not on concretions

5. Single Responsibility Principle (SRP)

Single Responsibility Principle (SRP) is one of the key desing principles for designing any software.

A class should have one and only one reason to change, meaning that a class should have only one job.

Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, a reason to change. The reason it is important to keep a class focused on a single concern is that it makes the class more robust. for example, there is RDAO class

For example, consider a module that processes and prints/displays a report. Imagine such a module can be changed for two reasons. First, the content of the report could change. Second, the format of the report could change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules.

Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.

What is a Responsibility here? Write in the comment section.

6. Open Closed Principle (OCP)

The Open Closed Principle is one of the important software design principles in SOLID design principles.

Software entities like classes, modules and functions should be
open for extension but closed for modifications

A class is closed, since it may be compiled, stored in a library, baselined, and used by client classes. But it is also open, since any new class may use it as a parent, adding new features. When a descendant class is defined, there is no need to change the original or to disturb its clients

For more details go Wiki page.

7. Liskov substitution principle (LSP)

Derived types must be completely substitutable for their base types
Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S.

Liskov’s Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy.

for more details go to Wiki page.

8. Interface segregation principle

Clients should not be forced to depend upon interfaces that they don’t use.
When we have non-cohesive interfaces, the ISP guides us to create multiple, smaller, cohesive interfaces. Smaller interfaces are easier to implement, improving flexibility and the possibility of reuse. As fewer classes share interfaces, the number of changes that are required in response to an interface modification is lowered. This increases robustness.

In conclusion, Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.

The ISP was first used and formulated by Robert C. Martin while consulting for Xerox

9. Dependency Inversion Principle (DI)

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

The dependency Inversion Principle states that we should decouple high-level modules from low-level modules, introducing an abstraction layer between the high-level classes and low-level classes. Furthermore, it inverts the dependency: instead of writing our abstractions based on details, we should write the details based on abstractions.

Dependency Inversion or Inversion of Control is better to know terms referring to the way in which the dependencies are realized. In a classical way when a software module(class, framework …) needs some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook (a property, parameter …) and an external module controlling the dependencies will inject the reference to the second one.

10. Important design points to remember apart from S.O.L.I.D. principles

Favour Composition over inheritance: Composition gives you a lot more flexibility, encapsulate a familty of algorithms into your own set of classes, also let you change behaviour at runtime. HAS-A can be better than IS-A. visit HAS-A vs IS-A
Program to an interface , not an implementation::
for example use
```
List list = new ArrayList();
```
not use ArrayList list = new ArrayList();
Identify the aspects of your application that vary and separate them from what stays the same: take what varies and “encapsulate” it so it won’t affect the rest of your code.
Pattern shows you how to build systems with good OO design qualities.
Pattern are not invented , they are discovered.

11. References

You can visit for more details about Software design principles or solid design principles.

I hope you enjoyed this post of Software design principles, and you can visit design patterns tutorial for more details
Happy learning! 🙂