我目前正在学习SOLID原则，尤其是SRP。
为了更好地理解这个原则，我记得刚刚开发过一个小应用程序，它有一个包含整个应用程序所有服务方法的Spring Service类。
Morevoer它有一个包含所有jpa数据访问方法的DAO类。这一切都明显违反了SRP。不是吗？
答案 0 :(得分：3)
嗯，是的，不，这里的想法是，如果一个班级只有一个“变革之轴”，那么它就是“SRP批准”（必须爱马丁的行话）。用凡话来说，这意味着：“这个班级改变的原因不止一种吗？”。 I.E.如果你的服务类infact聚合（比如说）调用其他服务的逻辑并对该服务调用返回的内容做一些业务逻辑，那么该服务类将有2个更改轴：一个用于何时/如果它调用的服务将改变，另一个改变业务逻辑。在这种情况下，调用其他服务的部分应该与将业务逻辑应用于返回结果的部分分开。
然而，这些东西被称为“原则”，而不是“法律”，因为它们不应该盲目地应用于你开发的任何东西，一直以来（以免你想要疯狂:)），但只有当上下文需要它时。
例如，Martin Fawler自己认为Model（作为Java bean）和DAO Objects分离是一种反模式，他称之为AnemicDomainModel。作为替代方案的一个很好的替代方案，请参阅Play Frameworks model implementation 。但是我确信你，以及许多其他人在Java中构建数据访问层时确实已经实现了这个bean / dao分离，并且代码本身是干净，可用和灵活的。