Linked above is the article I used for this week’s professional development blog post.
This week, in a continued effort to improve my fundamentals with Object orientated programming, I reviewed the five principles of SOLID. In doing so, I found a popular resource. The reason I chose this one for review though is that it cover’s every principle. And, each principle comes with examples in code and explanations of how the principles should be applied to programming.
Having all of the SOLID principles explained in a single place was attractive because I had no exposer to them before this class. This also means that nearly all the information within the web page was new to me.
Similar to the principles of GRASP, SOLID is fundamental to designing and writing code. It’s five principles (Single-Responsibility principle, Open-Closed principle, Liskov substitution principle, interface segregation principle, and Dependency Inversion principle) all contribute to making code much easier to refactor. Adhering to these principles means the subsequent software will be easier to maintain and extend. This is vital because all software I produce will need to be refactored. Both before and after it’s “finished.” So, for both my sake, and any other developer, it’s worth making sure I’ve understood these principles well. After reviewing and learning what each principle was, again just like GRASP, I was able to see how my past projects have embodied these principles. In fact, many times I was working with towards achieving these principles with my projects or working with them in mind without knowing they had a pneumonic device. In fact, many of the mottos of Object Orientated design are expressed in SOLID. Take the first principle of SOLID, Single-Responsibility. Simply put, it means any class or module should be only concerned with a singe part of the program’s functionality and that the functionality should be encapsulated. This immediately reminds me of “encapsulate what varies.” Adhering to this principle makes the code a lot friendlier to refactoring since a class would only be concerned with a single function or behavior.
Just like the first, all of the principles are the foundations to good code practices and many common design patterns. With this being the case, I can see that this is a subject I know in my sleep.