Rachel M. Carmena

Before learning SOLID principles

Published: 4 April 2019
Last updated: 27 May 2019


I’ve met a lot of people who are trying to learn SOLID principles and are struggling to remember: letter + title + statement.

I hope this post is useful to understand what they mean and why they are important.

An alternative list

SOLID principles are a set of design principles for object-oriented programming, although some of them could be good practices for other programming paradigms.

This is an alternative list:

  • Don’t mix unrelated responsibilities. I’m not particularly a fan of the definition of a responsibility as “one reason to change”, because I realized that it leads to confusion or it can be misinterpreted: Should a class have only one method?. Or if we are playing with CRC cards, we are talking about responsibilities for each class and even a general responsibility for each class could be enunciated. So I prefer pointing out “don’t mix unrelated responsibilities”, “this class/method is doing too much”, “look for high cohesion”, …

  • When adding new features, avoid doing a lot of changes in the existing code. It will be a signal that the source code is well-organized.

  • Think twice before designing with inheritance. Instead of an object, could you pass another one from a corresponding superclass without causing errors? Look for signals: Is inherited behaviour from a superclass being overriden?

  • When using an interface, don’t make me implement methods that don’t make sense. Look for signals: Do you find a name for the interface? Is it easy to find it? Are unrelated responsibilities being mixed?

  • Look for flexibility with abstractions, rather than concretions. Is there code depending upon specific implementation details? How easy is it to change a type?

Other principles with acronyms

There are other principles with acronyms like POLA, my favorite one:

When reading a class name, the content must match with that name and don’t include other responsibilities.

When reading a method name, the content must match with that name.

When clicking a button, the action must match with the context and its name.

In general, don’t surprise with things that aren’t expected.

Other principles:

Friendly reminder

Please, don’t shame a person who doesn’t remember the statement of a letter from SOLID principles. I think that following these principles when programming is more important than remembering the letter + title + statement from each of them.

Received feedback

Ricardo Borillo, a good friend and the first project manager I had in my professional experience, likes to explain the anti-patterns when SOLID principles are missing: singleton invasion, tight coupling, untestability, premature optimization, indescriptive naming and duplication. They form the acronym STUPID and are detailed in this article: From STUPID to SOLID code!.

Other resource


From Pragmatic thinking and learning. Refactor your wetware by Andy Hunt:

Don’t be in such a hurry. When problem solving, learn to be comfortable with uncertainty. When creating, be comfortable with the absurd and the impractical. When learning, don’t try so hard to learn and memorize; just get “used to it” first. Try to understand the meaning first; get the overall gist of it.

(…) simply mastering a syllabus of knowledge doesn’t increase professional effectiveness. It’s useful, certainly, but by itself it doesn’t contribute all that much to what you do in the actual, daily practice of your craft.

The model you build in your mind, the questions you ask to build that model, and your experiences and practices built up along the way and that you use daily are far more relevant to your performance. They’re the things that develop competence and expertise. Mastery of the knowledge alone isn’t sufficient.