What if the ReportService reached into the PayrollService' class and used its method? Then when it changes for legitimate payment purposes, the reports all change. "Wait, did he just mix up SRP and Cohesion?" No, but I'm glad you recognized the mix-up. tells you to make a change for the calculation for tax purposes for the actual payment method. If Senior Management asks to make a change in the calculation for employee pay for the sake of reporting, that's a different responsibility than if H.R. For example, PayrollService.CalculatePayFor(Employee) has the same exact code as ReportService.CalculatePayFor(Employee). What this really helps with is Proper Code Duplication. Observe their natural state and set up a wildlife preserve. When methods clearly belong together, you don't want to tear them apart. They are like a dang married couple, and they look great together. However, You Can Observe that CalculatePayFor(Employee) and Pay(Employee) are actually VERY Highly bound. There is no grouping of methods, methods are just methods that you can call whenever. Some languages even benefit from a complete lack of classes, and methods run free. You have classes named PayrollClass1 and PayrollClass2 because one does calculations one way, and the other does calculations two way. Each class now has one public method and everything is a well-defined mess. It is possible to create a class for every public method you want. What you do is Don't tear things apart that belong together. Perhaps Pay(Employee) calls into CalculatePayFor(Employee), but just because they have the word Pay in them doesn't mean they belong together! Imagine that you have a method decimal CalculatePayFor(Employee) and another method void Pay(Employee)ĭo these belong together? There could be a service that performs calculations of all sorts, and there could be a service that does nothing more than wrap the Human-Resources Payment SOAP. Nobody is saying to put all of your front-end code into one module and all of your back-end code into one module. With that as your new foundation for the definition of SRP, you can now apply what you thought SRP was previously, and make the definition a bit more granular. Therefore, A module (singular) should only ever change for one reason: The Single Person- Role for whom this module serves has requested a change. So when the Business Analyst asks to make a change to the algorithm, we shouldn't fear that the View will change. Because The module that handles Sorting on the View is responsible only to the stakeholder, and The module that handles the total-calculating algorithm is responsible only to the business analyst. When a Stakeholder asks for a change to the data-sorting in the View, management shouldn't freak out and worry that the algorithms will break. "Any module should be responsible to only one person-." (NDC 2012) "A responsibility is not 'something the code does'". put SendMessage() into a Message class!!" "The Employee class shouldn't UpdateDemographics() and SendMessage(), that counts as two responsibilities. Martin officially defines this principle as:Ī class should only have one reason to change Throw out whatever you think you guess this principle means. You asked: If not, how are they different? Single Responsibility Principle
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |