This is the last article of the SOLID series. In the previous article we’ve seen how to identify and fix a violation of the Liskov Substitution Principle.
OOP & OOD
A SO[L]ID refactoring exercise – Part 4
The solutions has once again been refactored, this time by applying the Open Closed Principle. Now the latest version of StudentService class looks like this:
A S[O]LID refactoring exercise – Part 3
In the previous article we covered the Single Responsibility Principle and continued refactoring the solution accordingly. As a result, now the Student class looks like this:
A [S]OLID refactoring exercise – Part 2
In the first part of the SOLID series we’ve looked at the Dependency Inversion Principle. After the initial refactoring attempt now the StudentService class looks like this:
A SOLI[D] refactoring exercise – Part 1
I initially planned to write about the SOLID principles in isolation, taking them one by one, defining them, and then coming up with a simple fit for purpose scenario complemented by some nice diagrams. But I soon I realised that almost all my knowledge on the subject, either coming from books or the internet, is based on the same type of articles.
Therefore, in an attempt to make things a bit more interesting, my approach is to have a single piece of code based on a scenario (as close as possible to real life) and work through refactoring this code using the SOLID principles. By doing this I’m hoping that this article will provide a bit more insight on how to spot and handle the violations of these principles, and also serve as good refactoring practice. And I promise, this is a guaranteed rectangle/square/shape -free post about SOLID.