PetClinic例子破单个责任原则

Question

我只是好奇加上也是为了更好的理解SRP，petclinic spring mvc例子有一个大的诊所有一个方法，可以让所有者，宠物和访问。

SRP，从另一方面说，“一个类（这里的实现类诊所/ inetrface本身的）应该做的一个任务定义。所以，后来诊所inetrface应该已经分成3个interafces？还是我的SPR /的PetClinic例如错误

Answer 1

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

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

并且它也提到了：

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

最后根据其original definition，SRP说

一类应该有一个，且只有一个理由去改变。

因此，设计与SRP一致，因为诊所接口封装了应用程序的持久性API，并且其实现将仅因所使用的持久性策略/技术的基本变化而改变。另一方面，如上所述，这是一个非常简单的例子，你猜对了，在一个更复杂的应用程序中，持久性/数据访问层很可能会被实体分割：通常你最终会得到一个每个主要实体的DAO，所以在PetClinic中就像OwnerDAO，PetDAO，VisitDAO一样。