Now, as you can see, each class has its separate job to do which exactly what the first SOLID principle states. To achieve the goal of the single responsibility principle, we should implement separate classes that perform a single functionality only.įor instance, for the GYM related stuff we will have BarbellWeightService…Īnd the same goes for the diet – NetCaloriesService…Īnd, of course, the separate class for creating the graphs – GraphService. ![]() But not only we are mixing up our gym and diet stuff in one class we are also mixing up our business and persistence logic which also violates Single Responsibility Principle. We always go to the same class which is not a very good approach. In this case our class has several reasons to be changed whether our athlete is working out in the GYM and adding some weights to the barbell or he/she is calculating the calories of their dinner, or they want to see the progress over period in the graph. Imagine there is a class AthleteService which handles athlete’s progress in the GYM, keeps track of the diet, and creates the progress graph. They also can choose exercises, save their progress of adding weights in exercises, and also they can track their diet. Let’s imagine that we have an app for GYM goers where a user can fill in his body parameters, like height and weight. Lower coupling – less job for a class – less dependenciesĪnd just in general, it’s easier to deal with small, well-organized classes, where it’s pretty obvious what job the class does.īut let’s have a look what happens when we omit Single Responsibility Principle.Merge conflicts – less job for a class – less reasons to change a class – less merge conflicts.Testing – less job for a class – less test cases.This principle states that “ a class should have only one reason to change” which means every class should have a single responsibility or single job or single purpose.įor instance, if we have a data model class, like let’s say Athlete, with the list of fields related to that entity, the class should change only when we change the entity.įollowing Single Responsibility Principle benefits us in: But the actual acronym was introduced later, in 2004, by Michael Feathers. They were first introduced in his paper Design Principles and Design Patterns in 2000. SOLID is an acronym for five design principles which are actually a subset of many principles promoted by American software engineer and instructor Robert C. ![]() In software engineering, if you want to have understandable, flexible, and maintainable object-oriented design SOLID principles is the direction to look at. ![]() What are the SOLID principles, why do we need them, and how to approach them correctly?
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |