publicinterfaceIPhone{
1. 　　　　//拨通电话
2. 　　　　voiddial(StringphoneNumber);
3. //通话
4. voidchat(Objecto);
5. //回应，只有自己说话而没有回应，那算啥？！
6. voidanswer(Objecto);
7. //通话完毕，挂电话
8. voidhuangup();
9. }

IPhone这个接口包含了两个职责：一个是协议管理，由dial()与 hangup()两个方法实现；一个是数据传输，由chat()与 answer()实现。

考虑：

Ａ.协议接通的变化会引起这个接口或实现类的变化吗？　会的！　　数据传输（电话不仅仅通话，还可以上网）的变化也会引起其变化！这两个原因都引起了类的变化。Ｂ.电话拔通还用管使用什么协议吗？电话连接后还需要关心传递什么数据吗？

都不，即这两个职责的变化不相互影响，那就考虑拆分成两个接口，类图如下：

这个类图略有些复杂，一个手机类需要把两个对象组合在一起才能用。组合是一种强耦合关系，还不如使用接口实现的方式呢。修改如下：

7.3　职责分明到接口

修改用户信息方法　－－－－〉　职责分明的方法

上述写法很糟（职责不清晰，不单一），改了吧。。。

7.4　分层架构模式（一个较大的单一职责示例）

分层架构模式实际上也体现了这一原则，它将整个系统按照职责的内聚性分为不同的层，层内的模块与类具有宏观的内聚性，它们关注的事情应该是一致的。例如，领域逻辑层就主要关注系统的业务逻辑与业务流程，而数据的持久化与访问则交由数据访问层来负责。以订单的管理为例，我们在领域逻辑层中定义如下的类OrderManager：

[java] view plain copy

@H_301_133@ @H_301_133@ @H_301_133@

1. classOrderManager
2. {
3. privateIOrderRepositoryrepository=
4. 　　RepositoryFactory.CreateOrderRepository();
5. voidPlace(Orderorder)
6. if(order.IsValid())
7. repository.Add(Order);
8. }
9. else
10. 　　thrownewInvalidOperationException("Ordercan'tbeplaced.");
11. }
12. voidCancel(Orderorder)
13. {
14. if(order.IsValid()&&order.CanCancel(DateTime.Now))
15. repository.Remove(Order);
16. else
17. newInvalidOperationException("Ordercan'tbecanceled.");
18. staticclassRepositoryFactory
19. staticIOrderRepositoryCreateOrderRepository()
20. returnnewOrderRepository();
21. }

@H_301_133@
OrderManager类的实现体现了单一职责原则的思想。

@H_502_59@首先，OrderManager类中的Place()和Cancel()方法均属于订单管理的业务逻辑，与领域逻辑层关注的事情是一致的。 @H_502_59@在这两个方法的实现中，我们需要检验订单的正确性（检验订单是否包含了必要的信息，如联系人、联系地址与联系电话），以及判断当前时间是否在允许取消订单的时间范围内。虽然它们仍然属于订单处理的业务逻辑，但拥有这些检查信息的是Order对象，而不是OrderManager，即Order对象是检查订单的信息专家。因此，IsValid()和CanCancel()方法应该被定义在Order类中。 @H_502_59@至于添加和移除订单的操作，虽然保证了下订单和取消订单的业务逻辑实现，但其实现却属于数据访问层的范畴，因而该职责被委派给了OrderRepository类。 @H_502_59@至于RepositoryFactory类，则是负责创建OrderRepository对象的工厂类。

这些类的职责以及协作关系如图2-4所示。

将数据访问的逻辑从领域对象中分离出去是有道理的，因为数据访问逻辑的变化方向与订单业务逻辑的变化方向是不一致的，引起职责发生变化的原因也不相同。这也是单一职责原则的核心思想。遵循该原则，就能够有效地分离对象的变与不变，将变化的职责以抽象的方式独立于原对象之外，原对象就更加稳定。MartinFowler认为，设计一个模型时应使该模型中最频繁修改的部分所影响的类型数量达到最少。我们对访问Order数据表的逻辑进行了封装与抽象，以隔离数据访问逻辑的变化，即使数据访问逻辑发生变化，它影响到的只是OrderRepository类而已。

7.5 　妥协示例（项目中常见的单一职责违背可接受示例）

所谓职责扩散，就是因为某种原因，职责Ｐ被分化为粒度更细的职责Ｐ１和Ｐ２.

比职：类Ｔ只负责一个职责Ｐ，这样设计是符合ＳＲＰ的。后来由于某种原因，需要将职责Ｐ细分为粒度更细的Ｐ１与Ｐ２，这时如果要遵循ＳＲＰ，需要将类Ｔ也分解为两个类Ｔ１和Ｔ２，分别负责Ｐ１、Ｐ２这两个职责。但是在程序已经写好的情况下，这样做简直太费时间了。所以，简单的修改类Ｔ，用它来负责两个职责是一个比较不错的选择，虽然这样做有悖于ＳＲＰ。

如，用一个类描述动物呼吸这个场景：

copy

@H_301_133@ @H_301_133@ @H_301_133@

classAnimal{
1. voidbreathe(Stringanimal){
2. System.out.println(animal+"呼吸空气");
3. classClient{
4. voidmain(String[]args){
5. Animalanimal=newAnimal();
6. animal.breathe("羊");
7. 运行结果：
8. 羊呼吸空气

@H_301_133@
程序上线后，发现问题了，并不所有动物都呼吸空气的，如鱼是呼吸水的。　 修改时如若遵循ＳＲＰ，则需将Animal类细分为陆生动物类Terrestrial ，水生动物 Aquatic，代码如下： [修改方式一]

copy

@H_301_133@ @H_301_133@ @H_301_133@

classTerrestrial{
1. classAquatic{
2. voidbreathe(Stringanimal){
3. System.out.println(animal+"呼吸水");
4. classClient{
5. voidmain(String[]args){
6. Terrestrialterrestrial=newTerrestrial();
7. terrestrial.breathe("羊");
8. Aquaticaquatic=newAquatic();
9. aquatic.breathe("鱼");
11. 羊呼吸空气
12. 鱼呼吸水

@H_301_133@
我们发现这样修改花销是很大的，除了将原来的类分解之外，还需要修改客户端。而 直接修改类Animal来达成目的，虽然违背ＳＲＰ，但花销却小的多，代码如下： [修改方式二]

copy

@H_301_133@ @H_301_133@ @H_301_133@

if("鱼".equals(animal)){
1. }else{
2. System.out.println(animal+"呼吸空气");
3. animal.breathe("鱼");
4. 鱼呼吸水

@H_301_133@
可以看到，这种修改方式要简单得多。但是却存在着隐患：有一天需要将鱼分为呼吸淡水和海水的鱼，则又要修改Animal类的breathe方法，而对原有的代码修改会对调用“羊”等相关功能带来风险， 也许某一天，你会发现程序运行的结果变为“羊呼吸水”了 。这种修改方式直接在代码级别上违背了ＳＲＰ，虽然修改起来最简单，但隐患却最大。还有一种修改方式： [修改方式三]