What is SOLID

SOLID is an acronym describing five basic design principles for writing good Object Oriented code. It is intended to make software designs more understandable and maintainable while also being less coupled and easier to extend.

They are a condensed subset of principals promoted by Robert C. Martin, also known as Uncle Bob, from his 2000 paper Design Principles and Design Patterns.

The individual letters of the SOLID acronym stand for:

  • S – Single Responsibility Principle
  • O – Open/Closed Principle
  • L – Liskov Substitution Principle
  • I – Interface Segregation Principle
  • D – Dependency Inversion Principle

Why should we learn these principals?

All of these principals are widely used throughout the Object-Oriented world, and worth knowing if you are to understand code written by others. These principals are all intertwined with and depend on one another. As we discuss these you will begin to notice some underlying themes and see how they build on each other.

These principals also have the side effect of allowing us to begin writing code that is… Reuseable, Easier to Maintain, Scalable, Easier to Test, and Easier to Understand.

While they are not laws or hard and fast rules, they can be a guideline and an exceptional learning tool. They make us analyze how our design will affect our codebase. How our changes will impact other developers. And how to create longevity and maintainability for our clients.

You see over time even the best-designed codebases can rot. There are many reasons for this. A quick bug fix hack that never gets refactored, a rushed feature that must be added yesterday, or rarely used code that is not understood and never updated. Even actively used code can rot due to new requirements that were not accounted for in the original engineered design.

When this happens the code becomes brittle and un-maintainable. This usually ends up requiring a refactor, or worse, a rewrite. You should recognize the symptoms of rot and brittleness when this happens and your code gets to this point.

  • Rigidity: Your code is difficult to change, even in simple ways.
  • Fragility: Your code breaks in many places every time it is changed.
  • Immobility: Your code is hard to reuse.
  • Viscosity: Even simple changes are hard to maintain.

By adhering to commonly used coding standards and principals, such as OO and SOLID, we can start to mitigate these issues. If we keep it simple, loosely coupled, and well thought out we can create software that will stand the test of time.

Let’s begin.