Understanding SOLID principles
As you might have guessed, SOLID is an acronym. I’ll go straight to the point, explaining what each letter stands for.
Single Responsibility — ; In this case, a responsibility defines any reason that necessitates the change of code, a class should have only one reason to change. These principles govern developers to prevent the use of a class to achieve more than one objective, considering an example where a piece of code that accepts input and generates a report based on this data, there are two possible reasons to change this code; the data input content could be changed and output format could also change, therefore this should now be split down to achieve a single responsibility.
Open-Closed — ; The behavior of a class should be extensible without modification. The extension of a class allows a developer to customize the functionality of a class as requirements specify. On the other hand, modification of a class externally is prevented through abstraction.
Liskov Substitution — ; This principle requires that derived classes be substitutable for their base classes. This, according to Robert C, each method should have defined preconditions and postconditions. These should be well documented for each method.
Interface Segregation — ; This prefers that we have many smaller interfaces than a few large interfaces. Breaking down interfaces allows a developer to leverage on composition, through separating by roles and decoupling classes from unnecessary responsibilities.
Dependency Inversion — ; According to Robert C, High-level modules should not depend on low-level modules, they should both depend on abstractions, and abstractions should not depend on details, details should depend on abstractions instead. Dependency inversion is aimed towards achieving high code reusability.