There are no shortage of acronyms in the field of computer programming. Some of those acronyms might come and go like a one hit wonder, others are here to stay. Robert “Uncle Bob” Martin first introduced the SOLID principles in the early 2000s and they’ve been around ever since. It’s an evergreen.
First they were just called “the first five principles” and is a collection of ideas brought forward by Robert Martin himself as well as other computer scientists before him. Just a few years later Michael Feathers came along and dubbed them SOLID which makes them a lot more fun and absolutely more memorable.
Uncle Bob argued that by sticking to these 5 “first” principles of software design, a system will be much easier to maintain and extend over time. Code that is written in adherence with the SOLID principles typically also turns out to be very clean and much more testable than code that violates them. If that’s not enough to pique your interest about a soon to be 20 year old set of ideas, I can reveal that the SOLID principles have stood up well against the tests of time. Each of the five principles are still very relevant and can help us write better code.
SOLID stands for:
- Single responsibility principle – Each class should be responsible for just one piece of functionality
- Open/closed principle – A class should be easy to extend by another developer without forcing the need to alter it’s source
- Liskov substitution principle – An object of a certain class should be replaceable by a subtype of that class.
- Interface segregation principle – A user/consumer should never be forced to depend on things it doesn’t use
- Dependency inversion principle – Avoid creating coupled code by making high level object independent of the lower level objects, and vice versa.
As with most things in life, there’s a balance between being dogmatic and pragmatic, between being short sighted or planning for the long run. In a series of five posts, I’ll be talking about the five principles and how they can help us write better WordPress themes and plugins.
Knowing about and understanding the SOLID principles isn’t a guarantee against unclean or bad code. Think of the principles as something to lean on whenever you’re trying to work out how to design your code.In my own work, I often find that the cause of a messy code problem is a bad overall design. Solving the design issues typically makes the coding part much easier.
So if you ever find yourself going too slow through a project because it has become too complicated, you could take a step back and consider the SOLID principles. They might be just what you’ve been looking for.
The first one is just out, read all about the single responsibility principle here.