Spread knowledge in your company: Print out 1-pagers and display them at the water cooler
Navigation Menu+

SOLID – Principles for Maintainable OO Code

Posted on Dec 2, 2013 by in Development, DevOps & SysAdmins | 5 comments

A short explanation of the 5 SOLID principles for object-oriented programming. The principles are:

  1. Single Responsibility
  2. Open / Closed
  3. Liskov Substitution
  4. Interface Segregation
  5. Dependency Inversion

These were grouped by Robert C. Martin, who invented 1), 4) and 5). 2) was formulated by Bertrand Meyer and 3) by Barbara Liskov. The acronym was coined by Michael Feathers.


The SOLID principle is controversially discussed. See this slide deck by Dan North for a concise critique.

Never miss a 1-pager – Subscribe to our free newsletter!

Content of the 1-Pager:

Single Responsibility Principle
Each class has a single purpose. All its methods should relate to function.
Reasoning: Each responsibility could be a reason to change a class in the future. Fewer responsibilities -> fewer opportunities to introduce bugs during changes.
Example: Split formatting & calculating of a report into different classes.

Open / Closed Principle
Classes (or methods) should be open for extension and closed for modification. Once written they should only be touched to fix errors. New functionality should go into new classes that are derived. This is popularly interpreted to advocate inheritingfrom an abstract base class.
Reasoning: Again you lower the odds of breaking existing code.

Liskov Substitution Principle
You should be able to replace an object with any of its derived classes. Your code should never have to checl which sub-type its’s dealing with.
Reasoning: Prevents awkward type checking and weird side-effects.

Interface Segregation Principle
Define subsets of functionality as interfaces.
Reasoning: Small, specific interfaces lead to a more decoupled system than a big general-purpose one.
Example: A PersistenceManager implements DBReader & DBWriter.

Dependency Inversion Principle
High-level modules should not depend on low-level modules. Instead, both should depend on abstractions. Abstractions should not depend on details. Details should depend upon abstractions.
Reasoning: High-level modules become more reusable if they are ignorant of low-level module implementation details.
Examples: 1) Dependency Injection, 2) Putting high-level modules in different packages than the low-level modules it uses.


  1. Please, consider rethinking the colors used in wall-skills as many of us have b/w laser printers and such light green might look too thin to be easily readable.

    • Hej Eduard, I’ve checked tha actual PDF, it looked quite ok in black/white. The green is much darker in the real PDF than in this preview, was ok here. Maybe you just have to alter the contrast of the print job a bit?

  2. Nice again. One typo in the L point — it’s no fun otherwise 😉 — “which which”.

    Anyway, thanks 🙂

    • Thanks for pointing out =)
      Right now Corinna has the template to fix these typos and is right now on a trip. But we will correct them soon 😉

  3. @Eduard: The colors are off in the preview images. Haven’t yet figured out how to fix this (the source file is in CMYK mode for the print PDF – somewhere there’s the problem…) – I’ve picked a darker green now anyway.

    @Clément: Thanks for spotting that! Fixed now 🙂


  1. Luke Merrett | The 3 Golden Rules of Awesome Development - […] Bonus:  The S.O.L.I.D. Principles in a handy wall chart here. […]

Submit a Comment

Your email address will not be published. Required fields are marked *