Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I am currently learning about the SOLID principles and especially the SRP.
To put this principle into perspective, I recall having worked on a small application a while ago that had a single Spring Service class that contained all service methods for the entire application.
Morevoer it had a single DAO class that contained all jpa-data access methods.
This is all in clear violation of the SRP. Isn’t it?
Well, yes and no, the idea here is that a Class is “SRP approved” if it has only one “axis of change” (gotta love Martin’s jargon). In mortal words this means: “is there more than one kind of reason for this class to change?”. I.E. if your service class infact aggregated (let’s say) logic that would call some other service AND do some business logic on what that service call returned, then that service class would have 2 axes of change: one for when/if the service it calls would change, and another for when the business logic changed. In this case the part that calls the other service should be separated from the part that applies the business logic to the returned result.
These things however are called “principles” and not “laws” because they shouldn’t be applied blindy to anything you develop, all the time (lest you wanan go crazy 🙂 ), but only when the context demands it.
Example, Martin Fawler himself deems the Model (as Java beans) and DAO Objects separation as an anti pattern which he calls AnemicDomainModel. As a good alternative to this, see Play Frameworks model implementation . However I’m sure you, as well as many other people have indeed made this bean/dao separation when building a data-access tier in Java, and the code itself was clean, usable and flexible.