The SOLID principles were originally defined by Robert Martin as a set of guidelines for writing better code. As with any guidelines, these are not steadfast rules that must always be followed but proper application of these principles can make code more maintainable, flexible, and readable. There is a plethora of information about these principles so rather than going into detail about each of them this article just includes a brief description of each one.
- Single Responsibility Principle (SRP)
A module should have one and only one reason to change.
- Open-Close Principle (OCP)
A module should be open to extension but closed to modification.
- Liskov Substitution Principle (LSP)
A derived class must be substitutable for its base class.
- Interface Segregation Principle (ISP)
Clients should not be forced to depend upon interfaces that they don’t use.
- Dependency Inversion Principle (DIP)
a.) Both higher and lower level objects should be based on abstractions.
b.) Abstractions should not depend on details. Details should depend upon abstractions.
One argument against using some of these principles is that following them will result in more code. Some may argue that having more classes and interfaces will ultimately make the system too difficult to understand. The counterpoint to these arguments is that there are no more moving parts in a system with many small pieces than a system with a few large ones. That is, if it’s doing the same thing it should be no more or less difficult to understand. The trade-off to more code is a system that is more accepting of change when (not if) it comes.