The principles of SOLID programming

The principles of SOLID programming

Hello there! Today I’ll be explaining The principles of SOLID programming. When I first got serious about OOP, I jumped to design patterns, but then I realized that everyone need a good grasp of the SOLID principles before you’re ready to tackle Design Patterns – in more of an Architect role – that is. So, to conclude this short introduction, I’ll try to explain this in as low-level of knowledge as possible.

Well, yous should know that SOLID stands for:

  1. Single responsibility principle
  2. Open-closed principle
  3. Liskov substitution principle
  4. Interface segregation principle
  5. Dependency inversion principle

Those are five basic patterns used in OO Programming and OO Design Those are the principles that can be used in agile and test driven development. Also, those are a good principles, good advices, but it’s not pure truth, nor is it a rule.Just a quote of a sentence I ran into internet: “They are common-sense disciplines that can help you stay out of trouble”. That’s why it’s a good idea.

Let me introduce you to them one by one:

Single responsibility principle

It states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. In other words the meaning of this phrase is that when you’re adding features to your application, two different, unrelated stories to implement should not affect the same class.

Open/Closed Principle

The meaning of this principle is that when a get a request for a feature that needs to be added to your application, you should be able to handle it without modifying old classes, only by adding subclasses and new implementations (in pure OOP language – extending old ones :D).

Liskov Substitution Principle

The meaning of this principle is that every time you extend a class, you have to make sure it is substitutable in every place where you use an instance of the original class. Extended class must respect the contract of the parent class. Meaning that you should edit it in a way so that it will stay recognizable compared the the parent class.

Interface segregation principle

This one means that you should avoid getting your classes included to other ones if only small portion of it will be used (say 3 out of 12). Often you will see classes with too much methods implemented in it which it’s not a good idea because it conflicts with Single Responsibility Principle in a way. Basically, if you don’t listen to this one, its considered to be a “bad design”.

Dependency Inversion Principle

Well, as last principle, I find it most valuable. It says that you should decouple your software modules. To achieve that you’d need to isolate dependencies. Why you might ask? Well, the answer is simple – for code re-usage. This way you’ll get more efficient and affordable at the same time. That’s why I find it most valuable.

In our environment (around 20 people) – this helps. It helps because when we have to do additional work on project done by other developer, you don’t have to trace code line by line, you only need to think logically, and you’re there. Besides the “Dependency Inversion Principle”, this I value the most in SOLID programming.

I’d like to conclude this one by repeating myself: “They are common-sense disciplines that can help you stay out of trouble”, they aren’t rules.


You made it all the way down here so you must have enjoyed this post! You may also like:

How to programmatically create customers in Magento 2.3.x Deni Pesic
Deni Pesic, | 2

How to programmatically create customers in Magento 2.3.x

90% of Magento websites are running on unsupported PHP versions. Why is this a problem and how can you (we) solve it? Aron Stanic
Aron Stanic, | 9

90% of Magento websites are running on unsupported PHP versions. Why is this a problem and how can you (we) solve it?

Development environment for Magento 2 using Docker Tomas Novoselic
, | 14

Development environment for Magento 2 using Docker


  1. It turns out that today Magento still keeps violating some of the SOLID principles. The greatest and most visible violation of SRP is the fact that M2 mixes concerns when places domain related business logic in the Model namespace. What goes within this directory should only belong to database related stuff(ORM, DAO etc).
    Domain related things should be abstracted away into a Business/Domain layer, all the things that make your applicatio valuable(constraints, business rules, policies etc) belong to Domain Layer focusing in a Design by Contract approach by defining the interfaces necessary to accomplish such a D.D.D standing point.
    there are other things that violate SOLID principles like for instance endless controller and model classes containing more than 1000 LOC but i’d look to other side if i consider it as infrastructure/low level modules that do not directly affect my Domain designing.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <blockquote cite=""> <code> <del datetime=""> <em> <s> <strike> <strong>. You may use following syntax for source code: <pre><code>$current = "Inchoo";</code></pre>.

Tell us about your project

Drop us a line. We'd love to know more about your project.