The SOLID Design Principles – Absolute Nonsense

One of the biggest pieces of nonsense in software engineering is the set of so-called SOLID principles. SOLID stands for SRP (single responsibility principle), OCP (open-closed principle), LSP (Liskov substitution principle), I (interface segregation principle), D (dependency inversion principle).

Inexperienced developers are awed by the majesty of a cool acronym. However, virtually every senior developer I know sees SOLID as a joke perpetrated on college computer science students.

The problem is that SOLID just takes a few very general principles for good OOP software design and then slaps labels on them. Take for example the LSP which says, and I quote, “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” Brilliant! All this means is that types that derive from a parent type should derive from the parent type.

Or take the SRP, “a class should have only a single responsibility (i.e. only one potential change in the software’s specification should be able to affect the specification of the class).” OK, suppose you have a business specification that defines a Book type. There can be many reasons for a change. Suppose you change a date field format from American style month-day-year to European style. Or you change the way Book IDs are defined.

Now, the underlying ideas behind SOLID are fine. But slavish devotion to a few general principles and the worship of acronyms is lame. In my world, if my colleagues and I asked a job applicant about SOLID and they parroted back definitions with a look of divine revelation on their faces, that applicant would be not rated highly. But an applicant who could demonstrate scenarios where basic OOP principles should be violated would get our respect.

Here’s my new acronym for good software design: the AWESOME principles. Software should be Awesomely recursive, Waterproof, Environmentally friendly, Slick, Open to inclusion, Magical and Extra special.