Real benefits of SOLID principles

Those SOLID principles many talk about are really helpful. But why use solid principles, why is SOLID important? Because they were stated and tested by advanced programmers in real situations? I say this is an enforcement, a reason to trust them, but not the reason to jump on them. It’s actually about understanding the benefits of using them and being able to identify when you need them.

All of them help in the way of having clean code. But why would you need clean code? You can really have messy code which does the same thing as the clean one. Except when you aim for long term healthy business. Solid code makes solid business.

Each of the SOLID principles comes with its ideology, but does not guarantee a 100% benefit, because there could be other factors which more or less collide with them, the first one being when you play around the principles, but do not apply them properly.

While the benefits you get from these principles are well known, I’d like to state some of them which for me are more real, more close to the business side.

Single Responsibility

If your code adheres to this one, it’s easier to be followed, understood, debugged, removed, and refactored. You can make more courageous changes. After some years you might want to (you’ll need to, you’ll be forced to) change things, and respecting this principle is going to be a vital key for easier changes. And if you break something, you break one thing (or fewer), not an entire system.

Open/Closed

By following it, changes and usage of objects become cheap in matter of time and risks. Objects can evolve with the possibility of working on them step by step, when needed, and not always feeling like you have to rewrite everything. When you can’t rewrite, just leave the past behind to be rewritten in small steps.

Liskov Substitution

It’s about many objects which can be easily replaced by objects of the same nature. New features around an existing one and changes are subjects of this principles. Integrate new objects fast.

Interface Segregation

Somehow goes towards the single responsibility. Your system’s user (the developer) will have a clear way to use exactly what they need, instead of being forced to interact with functionalities they don’t need. By not forcing them to handle what they don’t need, they need less code. Less code, fewer problems, closer deadlines.

Dependency Inversion

By sending dependencies from the outside world, you can change them more easily. And you know reasons for change: Libraries get really outdated or discontinued, business people change their mind, technical requirements change. If your code uses a dependency from outside (not only sent from outside, but also abstracted based on a contract), changing it will be cheaper. Also, you can test your units of code.

I see the need of a very strong balance between code and business, and the SOLID principles are all in for good business. As a desired side effect, you get happy developers who’ll be all in for the business on a long term.