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

Question

我只是好奇加上也更好地了解SRP，petclinic spring mvc例子有一个大的Clinic inetraface，它有所有者，宠物和访问的方法。

另一方面，SRP说“一个类（这里是Clinic / inetrface本身的实现类）应该定义一个任务。那么，那么Clinic inetrface应该被分解为3个interfces？或者我的SPR / petclinic示例错了？

Answer 1

假设您指的是SpringSource PetClinic example;文档说：

  

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

并且还提到：

  

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

最后根据其original definition，SRP说

  

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

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