My Experience Learning SOLID

My Experience Learning SOLID

Software Architecture Simplified

It is quite common nowadays when we think about the design of a solution, discussing about a technical problem or even just reading some article in Stack Overflow to come across with the term SOLID or at least one of the 5 principles that make up this acronym. The first time that I ran into this term was during my internship as a software developer, back in 2014... long time ago...

The world of design patterns and principles of software engineering was revealed to me, but at that time I was just a noob in software architecture and couldn't clearly understand the concepts or the real need for why we have to learn and implement such complex techniques and abstractions if we could instead implement our code in an easier way to solve today's problem not caring about tomorrow (scalability). Eventually, I found that this approach (development without proper planning and knowledge) is also a very popular methodology currently, a.k.a. Go Horse.


Months after I started to understand why learning SOLID was important as we had to manage dozens of different solutions and projects at the same time and it would be folly to do that leaving aside these principles. I will not go deep too technically in each principle in this post (I will leave it for the next posts) but I'd say in short that:

  • Single Responsibility Principle (SRP) helped to distribute correctly the responsibilities and reduce the number of dependent classes affected by a change.

  • Open-Closed Principle (OCP) was useful for allowing the creation of flexible code structures that minimize the chance of new bugs when the business requirement changes (frequently).

  • Liskov Substitution Principle (LSP) allowed to model good and logical inheritance hierarchies.

  • Interface Segregation Principle (ISP) was relevant to increase the readability and maintainability of the code reducing the amount of unnecessary code.

  • Dependency Injection Principle (DIP) was definitely necessary to reduce the coupling among the various projects by using abstractions between the layers.

One thing that we do need to know as well in advance is to be aware about when we should apply these principles, otherwise we run the risk of overcomplicating everything and use a sledgehammer to crack a nut.


The learning of SOLID principles and being able to see it in a practical environment pieced lots of OOP concepts together and helped me a lot to design better and scalable solutions.

Did you find this article valuable?

Support Victor Lins by becoming a sponsor. Any amount is appreciated!