Derick Bailey put together a set of Mo­ti­va­tion­al Posters to illustrate the SOLID principles. SOLID is a set of principles that help guide OO code towards greater testa­bil­i­ty. They increase cohesion and reduce de­pen­den­cies, hence, coupling.

Single Re­spon­si­bil­i­ty Principle — A class should have one, and only one, reason to change

Ideally, a class or a function will do only one thing and do it well, in only a few lines.

Recently, I refactored two large functions. One function proxied an HTTP request: it had to se­lec­tive­ly copy request headers, construct other headers, copy the request body, make the request, handle exceptions, se­lec­tive­ly copy response headers, construct other headers, and copy the request body. The preceding sentence tells you what the resulting functions looked like.

The other function made a series of related database queries, con­struct­ed some in­ter­me­di­ate data structures, then performed some joins, to build an object graph. Each query got its own function as did each builder of an in­ter­me­di­ate data structure. The top-level function became eight simple lines and is now com­pre­hen­si­ble.

Open-Closed Principle — You should be able to extend a class’s behavior, without modifying it

The classic for­mu­la­tion of the Open-Closed Principle is:

Software Entities (classes, modules, functions, etc.) should be Open for Extension, but Closed for Mod­i­fi­ca­tion.

That’s pithy—and confusing. Let me try restating it: don’t change existing code when you want to add new code.

If you’ve designed your system with abstract base classes and interfaces, then it’s generally possible to achieve this. If you have to add new if-clauses or adjust switch statements in existing code, your code is not closed for mod­i­fi­ca­tion.

Think “plug­gable” or the Template Method and Strategy patterns.

Liskov Sub­sti­tu­tion Principle — Derived classes must be sub­sti­tutable for their base classes

Interface Seg­re­ga­tion Principle — Make fine grained interfaces that are client specific

italic

Dependency Inversion Principle — Depend on ab­strac­tions, not on con­cre­tions