The SOLID Principles Video Series
I have just released the final video in my 5-part series on the SOLID Principles of software development. These videos are free to watch at www.DevEducate.com/series. You simply have to create an account with your email address and a password. That is all.
SOLID is an acronym coined by Robert C. Martin (Uncle Bob). SOLID Stands for:
- S ingle Responsibility Principle (SRP)
- O pen Closed Principle (OCP)
- L iskov Substitution Principle (LSP)
- I nterface Segregation Principle (ISP)
- D ependency Inversion Principle (DIP)
Each of these principles provides developers with guidance that will allow them to develop more maintainable software. While some of these principles are seemingly universally understood (SRP, for instance), others are not. The goal of this series is to explain each principle in layman’s terms and clearly outline the guidance each provides. The videos provide real-world(ish) demos to hammer home the points.
The following is an extremely high-level summary of what you will learn in each video:
Single Responsibility Principle
This video discusses what "responsibilities" are, providing concrete examples of classes that contain multiple responsibilities. It further discusses the dangers of violating the SRP from the following perspectives: 1) Coupling, 2) Simplicity, 3) Maintainability, 4) Testability and 5) The ability to respond quickly to change.
A tightly-coupled File Parser is used in the demos to illustrate violating the SRP and the challenges therein. A refactored version of the File Parser is used to illustrate adhering to the SRP. The session ends with discussing the benefits of adherence to this principle, as well as outlining some challenges that still exist that are addressed by other principles.
Open Closed Principle
This video clearly articulates what it means to be "Open for Extension" and "Closed for Modification". It discusses how, by programming to abstractions, we can prepare for predicted variations in our code. By predicted variation, I mean points in your code where you know change will occur. The session further discusses strategies for ensuring that you don’t over-engineer your solution and break other principles like YAGNI or KISS.
The session then discusses how the Strategy Pattern and Template Method Pattern can be used to help adhere to this principle. The File Parser from the SRP session is used to illustrate how we can take a solution that adheres to SRP, but not OCP can be refactored. It clearly outlines the benefits of adhering to OCP from maintainability and testability standpoints.
Liskov Substitution Principle
This video illustrates that when we program to abstractions (like we are directed to in the OCP), we have a reliance that types are substitutable for their base types. Unfortunately, the rules of subtyping are not strict enough to guarantee this substitutability. A more stringent set of rules is required, or the code that is programmed against the abstractions can (and will) fail.
LSP provides these stricter rules. The session discusses the 4 areas in which the LSP provides guidance: 1) Preconditions and Postconditions, 2) Covariance and Contravariance, 3) The History constraint and 4) Exceptions. Demonstrations are used to illustrate violations and dangers therein. We illustrate that violations often result in:
- Code that compiles
- Runtime errors
- Runtime type checking
- Violations in OCP
Interface Segregation Principle
This video discusses the fact that some classes that adhere to the SRP have non-cohesive interfaces. The ISP provides us guidance in these cases. It directs us to create client-specific interfaces. The video discuss the ISP from the perspective of both implementers of an interface, as well as from the consumer of an interface.
The session discusses the challenges of violating the ISP from the following perspectives:
- Recompile / Redeployment
A demo is used to illustrate the disadvantages of exposing a fat, non-cohesive interface to clients. The demo then illustrates extracting cohesive, client-centric interfaces and points out the advantages.
Dependency Inversion Principle
This video discusses the 2 distinct pieces of guidance provided by the DIP. The first is that high-level, policy modules should not depend upon low-level modules. Rather, the high-level modules should depend upon abstractions that the low-level modules implement. The second is the guidance of who owns the interface (the high-level, policy modules).
The session uses a demo to illustrate a discount calculator that does not adhere to either piece of guidance. The demo first refactors the solution to program to abstractions. It then illustrates that significant challenges remain even though we are programming to interfaces. These challenges stem from improper ownership of the interfaces. The code is then refactored to adhere to the second piece of guidance.
Throughout the session, the following areas are covered when discussing challenges to violating and benefits of adhering to the DIP:
- Tight Coupling
- Sensitivity to changes in low-level modules
I spent a lot of time trying to provide concrete examples of the benefits of understanding and adhering to these principles. I hope this is of some help to you, as Uncle Bob’s guidance was to me. Remember, the videos are free to watch!