My official interpretation of SOLID as of 7/2018

When people read about SOLID, they tend to think that SOLID is about writing the better code. It’s not. SOLID is about shaping the developer’s thoughts and revealing the uncertainties.

  • Single Responsibility Principle – a developer should be able to convincingly explain why they believe that this code has just one responsibility, and they also should be able to suggest the examples of changes that would make this code violate the SRP, and the examples of changes that would not.

  • Open/Closed Principle – a developer should be able to convincingly explain why this piece of code encourages extension and discourages modification. They should also be able to convincingly explain the difference between the extension and modification.

  • Liskov Substitution Principle – a developer should be able to convincingly explain why this hierarchy of classes makes sense.

  • Interface Segregation Principle – a developer should be able to convincingly describe the families of entities in the code, their roles and responsibilities, and why some of those entities have more than 1 role/responsibility.

  • Dependency Inversion Principle – a developer can convincingly explain why the code delegates the decisions it delegates, and why it doesn’t delegate the decisions it doesn’t delegate.