我目前正在学习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分离,并且代码本身是干净,可用和灵活的。