Robert C. Martin is a 68-year-old software craftsman (informally known as “Uncle Bob”) who collected ten object-oriented design principles. In this article, we will discuss the first five, more widely known as SOLID principles.

Respectfully, this acronym stands for:

SRP - Single Responsibility Principle.

OCP - Open/Closed Principle.

LSP - Liskov Substitution Principle.

ISP - Interface Segregation Principle.

DIP - Dependency Inversion Principle.

It all began in the year 2000 when Uncle Bob suggested that any successful software at one point or another will go through changes or further developments. Good design patterns decide how well the software will handle these changes in this process: If it becomes stiff and brittle, blame the inferior design principles.

That is why when our developers work on long-term outsourced software development projects, we always keep these principles in mind. Every update and tweak to the software may cause it to become rigid. These principles will help you avoid those troublesome situations:

SRP - Single Responsibility Principle

Robert explains the number 1 rule of class changes: to eradicate side-effects caused by changing the software; a class should have one and only one reason to change. If one single class has multiple responsibilities, it makes it that much more complex to change it.

It may not seem as important when you’re starting out with a project, but we always keep in mind that software is a dynamic product. So, one class = One responsibility, that is one SOLID rule we always follow to keep our products flexible.

OCP - Open/Closed Principle

Before Robert ever defined these principles, Bertrand Meyer was the first to note the “most important rule of object-oriented design” in 1988. In short, the second principle out of the five says that: “Every single software entity, be it classes, functions or modules, should be closed for modification, but open for extension”.

In short, when you’re writing the code, make sure that you’ll be able to add to it in the future without changing the original, existing code.

LSP - Liskov Substitution Principle

A year before Bertrand Meyer introduced his book; Barbara Liskov shone the light on what we now call the “Liskov Substitution Principle”. To explain it easily, the third principle suggests that superclass shall be replaceable with objects of its subclasses without breaking the application. But, of course, that requires the objects of your subclasses to behave in the same way as the objects of your superclass.

 If this principle is something you’re thinking of using in your code, you should keep in mind that the behaviour of the code becomes significantly more important than its structure.

ISP - Interface Segregation Principle

This may be the most basic but also the most underrated principle out of the five. When Robert was consulting a very famous company, he coined the following principle: Clients should not be forced to depend upon interfaces that they do not use.

All of our developers think that writing working software is essential, but they always press the importance of self-explanatory, well-made software. When we’re working on an outsourced software development project, we never violate this rule because ignoring this significant principle results in two unfortunate outcomes:

• Developers from our client’s side would be confused by the methods they clearly do not need
• A change in interface forces the developers to change the classes that don’t implement the interface, so maintenance becomes harder to do.

DIP - Dependency Inversion Principle.

According to Robert, the last, but never the least, fifth principle is: High-level modules shouldn’t depend on the lower-level modules. Also, details should depend on abstractions, not the other way around.

This principle is the easiest to follow if you keep the previous four in mind. Basically, it is a continuance of other SOLID principles. If you keep up with the O and L rules, you’re also adhering to the last one.

When we work on our outsourced software development projects, we always keep in mind that ever-changing software should be easily tweaked, without complications and mistakes. This makes our products flexible and well-crafted. So thanks, Uncle Bob, for the fascinating SOLID principles that we think every developer must follow.