设计模式学习- 单一职责原则

单一职责原则的定义：

只能有一个原因引起类的变更

单一职责原则的优点：

1.类的复杂性降低， 实现什么职责都有清晰明确的定义；
2.可读性提高， 复杂性降低， 那当然可读性提高了；
3.可维护性提高， 可读性提高， 那当然更容易维护了；
4.变更引起的风险降低， 变更是必不可少的， 如果接口的单一职责做得好， 一个接口修改只对相应的实现类有影响， 对其他的接口无影响， 这对系统的扩展性、 维护性都有非常大的帮助。
单一职责原则的总结：

单一职责原则并不是绝对的，也要视情况而定，和项目的工期，成本，人员水平息息相关。不过一个接口的方法一定要做到单一职责，因为如果做不到的话一旦接口或者方法发生改变那么相应的实现者或者调用者也要相应的做出改动，对系统的影响比较大，可维护性和可扩展性大大降低。而对于类则尽量做到只有一个原因发生变动，因为系统的变更是无法避免的，一旦发生变更如果能做到只增加相应的接口而对应的类只需要实现该接口那么还是比较理想的。

 

举例：比如一个电话接口，它有4个方法，一个是打电话，一个是发送短信，一个是发送彩信，一个是上网。

所有继承这个接口的类都要实现这4个接口，问题是有的电话是不能发送彩信的，比如诺基亚的黑白机，

有的电话是不能上网的。但是这些电话都要实现一些它其实不能实现的方法，而且每次这个接口增加一个方法他它们都要实现，比如蓝牙，无线传输等。

因为一个接口的改变会改变他所有的实现类，这样的话即使是黑白机也要实现发送彩信，上网和无线传输的功能，这样的话程序就会变的比较混乱。例如有时候调用者明明调用了一个发送彩信的接口却发现根本没有发送出去，后来才发现原来是这个手机不支持 。程序的结构变的非常的模糊，不够清晰明了，我们有时候甚至不能确定某些功能是否可以使用，同时也给后期的维护和扩展带来了很多麻烦，因为一旦改变某个功能就可能需要对应的变更其他依赖于该功能的模块，即使这些模块并不需要这些功能。这就是不遵循单一职责原则带来的坏处。

   那么试着想想如果我们在一开始就将这个接口拆分为3个接口，第一个接口有打电话和发送短信的功能，另外两个接口分别只有一个方法，那就是发送彩信和上网，他们可以继承第一个接口也可以不继承，看具体情况。

那么黑白机就可以实现第一接口，彩屏手机可以实现第二个能发送彩信的接口，智能手机实现第三个能上网的接口，这样一来程序的功能就比较清晰了，因为每个类只实现自己可以实现的方法。这样调用者也可以清楚的知道自己调用对象的某些功能确实是可用的。可扩展性和可维护性也大大提高，每次的变更都只针对于那些确实需要变更的模块，而不会发生做一些小的功能变更就要改一大片代码的情况。