If more than one scores between "reasonably likely" and "my code has already changed for that exact reason", then you are violating SRP against that kind of change. What I can do is brainstorm possible changes based on what I've seen in the past, and you can subjectively rate how likely they are. How many reasons does your Employee class have to change? I don't know, because I don't know the context in which you're using it, and I also can't see the future. My favorite definition of the SRP is: "a module/class/function should have only one reason to change." Arguing about likely reasons for your code to change is much more productive than arguing about whether your code is SOLID or not. The first two letters in SOLID, SRP and OCP, are both about how your code changes in response to a change in requirements.
There are already great answers pointing out that SRP is an abstract concept about logical functionality, but there are subtler points that I think are worth adding. Update: The example has been generously updated by guntbert to make the method more realistic and help us focus on the underlying discussion. If I had replied, I would have started by pointing to the paradox mentioned above, and then indicate that the SRP is highly dependent on the level of granularity you want to consider and that if you take it far enough, any class containing more than one property or one method violates it. I decided not to reply to his many arguments, but I am curious what the community thinks on this question. I found this claim really surprising, as following this reasoning, any class having one property and one method violates the SRP, and therefore OOP in general is not SOLID, and functional programming is the only way to heaven. You are violating the single responsibility principle (SRP) as you are both representing data and performing logic in the same class." Public void AddPaidDaysOffGranted(int numberOfdays)Īs he defended his anemic model approach, one of his arguments was: "I am a believer in SOLID. Public Employee(string firstName, string lastName) And I demoed my point with a simple class looking like that: public class Employee I was explaining the benefits of having a rich domain model as opposed to an anemic domain model.
0 kommentar(er)
