One of the topics of this class that I don’t know much about is SOLID. Most of the programming I have done has been very small projects that do not necessitate the use of very many design principles. This is not to say they should be applied but they add quite a bit of extra work to something that doesn’t require very many lines otherwise.
Because of my lack of experience with it, I chose to learn a little more about SOLID starting with the “S” – Single Responsibility Principle. I found an article from stackify.com to explain it further.
The principle is self-explanatory. Uncle Bob describes it as “A class should have one, and only one, reason to change.” This is important because it makes your software easier to implement and prevents unexpected side-effects of future changes.
When a class has multiple responsibilities, these responsibilities are no longer independent of each other. If one responsibility needs to change, the more often the class needs to be changed. This may not seem like a big deal but if some things depend on the changed class you may need to update dependencies of recompile dependent classes. To avoid having to change many components to make a single change, give each class only one responsibility.
It also makes your code easier to understand. If there is a problem somewhere it is easier to isolate the problem.
While each class should have one responsibility, this shouldn’t be taken too far by, for example, making each class have only one function.
The article also provides some real-world examples showing the Single Responsibility Principle in action.
I am often guilty of violating this principle. For a project I once made a Pokémon battle simulator. Looking back now I really broke this principle with that one. I had a class to make Pokemon objects and another to do everything else. Because it was for a database course, I connected to the database and had a battle method all in that class.
For the final project I will have to make sure I do my best to stick to the SOLID principles and not get caught in just making the code work. Because it is a group project, I need to be sure the code is easy to understand to others and not just myself. The Single Responsibility Principle is a big part of that.