spring - PetClinic 示例是否违反单一责任原则

Question

我只是好奇加上更好地理解 SRP，petclinic spring mvc 示例有一个很大的 Clinic inetraface，其中包含所有者、宠物和访问的方法。

另一方面，SRP 说“一个类（这里是 Clinic/inetrface 本身的实现类）应该完成一项定义的任务。那么，Clinicinetrface 应该被分成 3 个接口？或者我把 SPR/petclinic 的例子弄错了？

Answer 1

假设您指的是 SpringSource PetClinic 示例；文档说：

PetClinic 的高级业务/持久性 API 是 org.springframework.samples.petclinic.Clinic 接口。PetClinic 中的每个持久性策略都是 Clinic 接口的不同实现。

并且还提到：

由于 PetClinic 应用程序都是关于数据库访问的，并且除此之外应用程序中几乎没有业务逻辑，因此主要业务和持久层 API 没有分离。虽然这种设计技术不应该用于具有更复杂业务逻辑的应用程序，但在这里它是可以接受的，因为所有与持久性无关的业务规则都已在业务对象中实现并且没有泄漏到持久层中。设计中最重要的方面是业务层和持久层完全独立于表示层。

最后根据其原始定义，SRP 说

一个班级应该有一个，而且只有一个改变的理由。

所以在某种程度上设计与 SRP 是一致的，因为 Clinic 接口封装了应用程序的持久性 API，并且它的实现只会因为所使用的持久性策略/技术的底层变化而改变。另一方面，正如它所提到的，这是一个非常简单的示例，您猜对了，在更复杂的应用程序中，持久性/数据访问层很可能会被实体拆分：通常您最终会拥有一个每个主要实体的 DAO，因此在 PetClinic 中类似于 OwnerDAO、PetDAO、VisitDAO。