The SOLID principles of object oriented design are single responsibility principle, open/closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. I went over these a bunch of years back when I think it was Matt Ozvatt started a discussion on the topic. At the time I was busy with work and life and probably didn’t give them the focus they deserved. Today, I’d like to review.
The single responsibility principle is the notion that each object should have a single responsibility. This sounds insanely simple and intuitive, but in practice it is not and part of the reason is evolution of the code. For example, it may make sense to have a car object early in a project and that object does everything a car does. As things progress and get more complex, there may be a time when you need an engine object, a transmission object, etc. As long as you are open to constant refactoring, you will create these objects when needed.
The open/closed principle is the notion that software entities should be open for extension, but closed for modification. The principle sounds simple enough, but in practice it doesn’t make too much sense to me. The idea that I would ever be done with any class is hard to fathom.
The Liskov substitution principle states that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. The interesting covariant argument example for this principle is say you have a Person class and Child is a subclass of Person. Person has a see(Doctor) method and Pediatrician is a Doctor. The see method does not enforce that the Child must see the Pediatrician.
Interface segregation principle status that many client specific interfaces are better than one general purpose interface. Basically, this means once a interface becomes “fat” you should split it up. Just about every project has some interface that because bloated and everyone is afraid to change. The longer you wait, the worse it gets.
The dependency inversion principle is the notion that one should depend upon abstractions, not concretions. The idea is that if higher level objects are not dependent on lower level objects, there may be more reuse.
The SOLID principles are in some ways academic discussions of how code should be rather than how it is most of the time. Am I going to write a service locator to find a logging object or just deal with the fact that my class is dependent on log4j? Chances are I’m going to just use log4j.