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.
Articles for August 2015
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.
A Web API & Angular starter project using Azure AD Identity
Having worked on a few greenfield projects in the last couple of years I always found myself eager (and sometimes under pressure) to get a good grasp of the domain and start delivering business value from day one.
While this is an ideal scenario, in reality a good part of the first sprint is usually spent setting up the working environment and drafting a high level architecture. And although this how it should be (you don’t want to start coding without some planning), once an architectural and technological path for the project is agreed, I sometimes felt it would be helpful to be able to fast forward through the repetitive parts of this process, especially if it’s something already familiar and proved to be working.