blog2 (1)

SOLID Principles easily explained

Reading time: 5 min

Clean code – is one of the most important commandments for many programmers. Why? Clean code not only allows for a better overview, more flexibility and easy maintenance – on top of that it is also easy to understand for other programmers who work with it or deal with the code. One way to do just that is through SOLID principles. In our Jungle Academy, our internal format by developers for developers, the SOLID Principles were presented. Want to try your hand at coding for the first time? Then be sure to follow the SOLID Principles. What these are we explain in this article.

The SOLID Principles form an important foundation for Clean Code. The SOLID principles were introduced by Robert C. Martin aka Uncle Bob, but not all of them are his. Why you should stick to it? Easy – the SOLID principles help us to do this:

But first: What is a principle in software development anyway?

Principles are rules or laws that must always be followed during development – you could compare it to the simplest math rule: dot before dash. You could also say: They are there to solve or simplify problems. They also help you and your team ensure that the resulting software has certain characteristics. The properties depend on the principle.

What do the SOLID Principles mean in full?

SingleResponsibility Principle
LiskovSubstitution Principle
InterfaceSegregation Principle
DependencyInversion Principle

TRIGGER WARNING: It’s getting technical!

Single Responsibility Principle

A system has only one task

A class should have only one responsibility and there should be only one reason why you want to change the class. Do one thing and do it well! The result is an architecture that is clear, understandable and more maintainable . Failure to follow the Single Responsibility Principle creates potential maintenance problems in the software. For example, other areas and functionalities may be negatively affected by this.

Advantages of the Single Responsibility Principle:

✔️ Easy maintenance: Since you define a clear purpose for each class, it is easier to maintain because it is smaller and clearer
✔️ Avoidance of side effects in relation to other responsibilities for changes
✔️ Better collaboration: Work in programming teams can be better divided, because each programmer can then work on a class for which he/she is responsible.
✔️ Keeps dependencies to a minimum when reusing classes
✔️ Small classes greatly simplify troubleshooting
✔️ Possibility to assign clear and meaningful class names, since each class has a responsibility
✔️ Decoupling implementations based on what is likely to change together
✔️ Ef fort for development and testing is reduced

The Single Responsibility Principle

Open-Closed Principle

Modules should be open for extensions, but closed for modification (changes)

Basically, the Open-Closed Principle is about being strategic, because it requires that written code (which has also been tested) should no longer be changed, or to construct the software design in such a way that changes can be supported without completely rebuilding the system.
How this can be achieved? By inheritance or by providing the module with an interface. This does not change the already existing behavior of the module, but only extends it with additional functions or data.

Advantages of the Open-Closed Principle:

✔️ Errors are avoided because code that has already been written is left alone
✔️ Software becomes more maintainable
✔️ Reuse through the design of stable interfaces

The Open-Closed Principle

Liskov Substitution Principle

If a derived class is to be implemented, the base class must be extended without changing the behavior of the base function

In simpler terms, subclasses must behave like base classes. The Liskov Substitution Principle is actually a substitutability principle. This is about interchangeability across class inheritance hierarchies: subclasses must behave like base classes. Look at the graphic with the square and the rectangle: There is a relationship between squares and rectangles: you can say every square is a rectangle, but not every rectangle is a square. You already notice, in programming this inheritance relation would not work.

So how can you solve this in programming? Instead of inheriting square and rectangle, one introduces a third class from which both square and rectangle derive. Thus, the square and the rectangle are coupled only via the new third class.

Advantages of the Liskov Substitution Principle:

✔️ Security that an implementation can be replaced without changing its behavior

The Liskov Substitution Principle

Interface Segregation Principle

Each class should be focused on one aspect or topic only

The Interface Segregation Principle deals with the separation or decoupling of classes. In the Open-Closed Principle, we learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it becomes increasingly difficult to provide a complete implementation as more and more code needs to be added.

The solution? Do not let interfaces become large in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.

Advantages of the Interface Segregation Principle:

✔️ S implifies reuse, testing, and maintenance by sharing responsibilities
✔️ Insulates classes from errors by introducing clear boundaries
✔️ Allows functions to be replaced without having to understand related classes
✔️ Lowers cognitive load by isolating topics
✔️ Focuses attention on a single aspect

The Interface Segregation Principle

Dependency Inversion Principle

Higher level classes should not depend on lower level classes

The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests to include an interface to decouple two classes from each other. Thus, the first class references the interface and the second class implements the interface, so the second class (because it contains the appropriate interface) can be inserted into the first class as a parameter.

Advantages of the Dependency Inversion Principle:

✔️ Enables reusability of high-level classes by inserting classes
✔️ Since implementations can be exchanged, low-level changes are facilitated
✔️ Code simplification through uniform working with alternative classes
✔️ Improves testability

The Dependency Inversion Principle

Conclusion? Sounds SOLID!

As you can see, SOLID principles simplify coding and help you achieve clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:

“The SOLID principles are the foundation of our work. They are easy to learn, but difficult to master. They are one of the first pieces of content we teach young developers to give them the right entry into software development. Today, even after several years of experience, we always point out violations of these principles with a grin. The other moans at having been caught in a beginner’s mistake and corrects his work.”

Start your project with our software development!

The author
Editor & copywriter
Huyen uses her flair for language to make texts lively, appealing and effective.
MicrosoftTeams-image (110)