单一职责原则

这个原则说起来非常简单，定义是：应该有且仅有一个原因引起类的变更。就是一个类只有一个职责，说到这里，很多人都会不屑一顾。因为它太简单了，简单得不需要我们更加深入的思考，单从字面上就明白了什么意思。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。

确实，大部分时候很容易遵守这个原则，但是有些情况下，即使经验丰富的程序员也会违背这一原则。

1.This is sometimes hard to see，确实，职责有时候很难判断，如果你想和别人争执、怄气或者吵架，这个原则屡试不爽。怎么划分职责，应该细化到什么程度等等，都需要从多方面考虑，也受经验、能力等制约。比如对一个表的增删改查，放到一个类中，还是四个操作作为职责都单独拿出来，简单的小业务放一起比较容易，如果每个操作都很复杂，受N多方面制约，比如增加时不单单保存到数据库那么简单，可能同时保存到多个位置，或者文件从其他系统读取数据，发送很多消息，涉及协议等，可能就要单独划分了。

2.职责扩散，写代码的时候，大家都写的很好，每个类都一个职责，可惜会有种种原因，比如需求变更，设计者水平上升，想重新设计等。只有一个职责的类被分化成两个职责了，可能为了成本，为了方便，或者疏忽（大部分原因是忽略）等，我们没有拆分，没有重构，日积月累，一个类往往多个职责了。

类似这种代码，就是明显违反了单一职责原则

public void changeUser(IUser user,Map<String,String>options);

这个接口方法，可以修改user不同的功能，修改密码，修改名字等都可以，这个方法粒度很粗，而且不能看出来这个方法能干什么，不能干什么，千万不要这么写，如果有人这么写，重构吧。

单一职责原则的好处：

1.降低了类的复杂度。一个类只负责一项职责比负责多想职责要简单得多。

2.提高了代码的可读性。一个类简单了，可读性自然就提高了。

3.提高了可维护性。可读性高了，并且修改一项职责对其他职责影响降低了，可维护性自然就提高了。

4.变更引起的风险变低了。单一职责最大的优点就是修改一个功能，对其他功能的影响显著降低。

生搬硬套单一职责，只会引起类的剧增，就会给维护带来很多麻烦，所以原则是死的，人是活的。单一职责提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计是否优良，但是“职责”和“变化原因”都不是可度量的，因项目而异，因人而异。