In this post, I would like to explain to you what exactly is SOLID. I will try to do it the clearest way I can.

At first, you should know that SOLID consists of 5 design principles that were created to make software more understandable, flexible and maintainable. They’re gathered by Robert C. Martin in 2000.

Now, let’s go into details about those principles. They’re listed below with definitions. Also under each definition you’ll see my keyword – the only one word that (for me) describes best the whole rule (and was introduced to me on some presentation about SOLID principles).

Single responsibility principle

This rule simply means: focus on only one element. So, let’s say you have two aspects (e.g. content and cover) of the one problem (e.g. printing a book) – they’re two separate single responsibilities (so should be in separate classes/modules). It would be a bad design to couple two things that can change for different reasons at different times.

Keyword for this principle is: focus.

Open-closed principle

Your application should be open-closed. It means that it should be possible to add new functionality without changing things that has already been written.
Maybe not perfect example but intuitive: look at your browser. I’m sure that you have some add-on to it. And that is how this rule works – you don’t modify the code of your browser to add a new functionality. You just add some plugin to it.

Keyword for this principle is: plugin.

Liskov substitution principle

This principle says that when we extract one module from the application and insert another module instead, the application should not change its purpose. The inheriting class should only expand the capabilities of the base class and, in a sense, not change what it did before. In other words, if we create a copy of a child class, regardless of what the variable pointer finds, calling the method that was originally defined in the base class should give the same results.

Keyword for this principle is: contracts.

Interface segregation principle

This rule simply tells us to avoid using one large interface and advises us to divide it into smaller ones. For example, one large interface can be divided into the first one, which would contain declarations of three methods that would be implemented in all classes (“public” ones) , while the other would define declarations of the other two methods that were not used everywhere (“secret” ones). The classes would implement one or two interfaces depending on current needs.

Keyword for this principle is: secrets.

Dependency inversion principle

This rule can be divided into two important rules:

• High-level modules should not depend on low-level modules.
• Abstractions should not depend on the details (specific implementation). But details (implementation) should depend on abstraction.

In the simplest terms, creating an interface is sometimes not enough – the place where it is created and the wider perspective is also very important.
When creating the interface, first of all, we should think about the main class, which will consume it, not the “class of detail” that will implement it.

Keyword for this principle is: demands.

That’s all about the SOLID principle. Getting to know them is the easy part.
But now, I would like you to do the harder one – remember & use them in your projects! 🙂