面向对象设计的原则--单一职责原则（SRP）

概述

职责： 是引起变化的原因

如果有多于一个的动机去改变一个类，这个类就具有多于一个职责

把多个职责耦合在一起，一个的变化可能会削弱或者抑制这个类完成其他职责的能力

SRP ： 对一个类而言， 应该仅有一个引起它变化的原因。

SRP例子一

这个设计违反了单一职责原则（SPR）。Rectangle提供了两个职责。第一个职责提供了一个矩形集合形状的数学模型，第二个职责把矩形绘制在图形界面上。



将两个职责分离到上图的所示的完全不同的类中。

SRP例子二

SRP例子三

public interface Modem{
public  void dail(String phoneNum);
public void hangup();
public void send(String msg);
public void recv();
}

上图所示是一个调制器类，该接口显示了两个职责。第一个职责是连接管理，第二个职责是数据通信。上面两个职责应该被分开吗？这依赖于应用程序的变化方式

如果应用程序的变化会直接影响连接函数的签名，那么就需要分离。

如果一个应用程序的变化方式总是导致这连个职责同时变化，那么就不必分离它们，避免过度设计带来的复杂性。

结束

日常的业务开发过程中会遇到这样的情况业务类（SERVICE）往往会频繁变化，而持久化类（DAO）却不会如此频繁的变化并且变化的原因也是不同的。这个时候就需要分离类的职责。

如果一个类承担多于一个的职责，那么引起它变化的原因就会有多个。一个类的变化可能会削弱或者抑制这个类完成 其他职责的能力。

单一职责并不是说一个类只需要做一件事，而是说一个类需要做一类事。类的概念本身就是指提供一套模板出来。真正使用的是类的实例(也就是具体到某个对象)，所以我们在设计类的时候需要站在设计师的角度来考虑。举个简单的例子，我们使用ssh框架一般service里面都是增删改查的方法.如果说站在业务上来看，业务简单，那这样设计，就可以说这个service是单一职责，负责CRUD，如果我们是用ssh做很复杂的业务，一个查询，一个增加都有很多的逻辑在其中，那这个时候我们是不是要考虑把查询和增加这些功能在类中给分离出来，让增加类负责增加的逻辑，让查询类负责查询的逻辑，这就是需要根据业务系统的复杂度来均衡判断单一职责了，这里的单一不是指一个，指的其实是一类或者说一种而已。

我们会自然把职责结合在一起。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。