SOLID 2020 and beyond

-

One of my favourite set of principles as a developer has always been the SOILD principles. I believe they promote well thought out code, and that if you aim for those principles, no matter where you end up, it's usually a pleasant place.

I wanted to take a look at how SOLID fits in the 2020 landscape of cloud, serverless, containers etc and see if the lessons these principles teach us are still relevant in today's world.


I would argue that these principles are as relevant today as they've always been. The benefits of employing the Single Responsibility Principle in Lambda API endpoints on AWS, for example, are the same as in classes or objects.

In my experience, the simpler the code, the easier it is reason with, deploy and ultimately, maintain. That’s not to say that you should beat yourself up if you find your objects/classes don't meet the SOLID principles exactly, they're principles to aspire to, not a blood oath. Question whether what you're building is appropriate, if it is, note down why you've made the choices you have and move on.

What are your thoughts on the relevance of SOLID?

Popular posts from this blog

I is for the Interface Segregation Principle

-
The "I" in SOLID stands for Interface Segregation Principle. It's more of a mouthful to say than it is to understand. It states : Clients should not be forced to depend upon interfaces that they do not use. Succinct right? i.e. Keep your interfaces as small and modular as possible. It maximizes their potential for reuse and prevents clients/end users from depending upon functions/methods they don’t really need.
Read more

S is for the Single Responsibility Principle

-
The "S" in SOLID stands for Single Responsibility Principle, and it’s probably the principle that gets the most bad press. It states that each class should have just one responsibility. My take on this is that this principle is another way of saying Keep It Simple Stupid (KISS). To quote Robert Martin himself : A class should have one, and only one, reason to change. One of Uncle Bob's favourite examples is "an “Employee” class that calculates the pay and saves the employee data to a persistence store. If there's a change required in how pay is calculated, the class will have to be changed. If the DBA makes some changes to the database schema, the class will probably have to change as well." Here the "Employee" class has two responsibilities which violates the SRP. One is business logic related and the other data infrastructure related. According to the Single Responsibility Principle, these concerns shouldn’t reside in th
Read more

L is for the Liskov Substitution Principle

-
The "L" in SOLID stands for the Liskov Substitution Principle. In my opinion, this has the most complicated definition, but the most obvious implementation, you're probably doing this without thinking about it. This principle is named after Barbara Liskov, who  defined it in 1988 as : What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behaviour of P is unchanged when o1 is substituted for o2 then S is a subtype of T. Eh? Robert Martin defines it as : Derived classes must be substitutable for their base classes. In my mind, this is one of the most fundamental principles of Object Oriented Programming? Definitely a staple when learning Java at University (I certainly remember this. "Dog and Cat are both types of Animal …"). Dependency injection frameworks put this into practise by supplyin
Read more