设计模式六大原则之单一职责原则

本文参照《设计模式之禅》一书，各位看官如果有兴趣可去通读全书。

开篇简单说两句废话，个人建议学习设计模式之前，应了解设计模式六大原则，毕竟设计模式是六大原则的完美体现和运用。可以对学习设计模式有一个风向标的作用（仅个人见解）。所以本人先给各位看官介绍六大原则。

举个栗子：（本人能力有限，只能说一些个人理解，若有不当，欢迎吐槽！！！！！）

比如一个public类中的main（）方法我们要实现一个人吃饭，喝水，玩耍，睡觉，打豆豆这些逻辑；

我们在整个main方法通篇一顿写，没问题，肯定能实现。你感觉展示自己才华的时候到了，这个必须得封装啊，但由于功力不够，吃饭、喝水、玩耍、睡觉逻辑写一个方法里了。经理看完之后唠叨了你两句，你这么写怎么怎么滴……，于是乎你和老板一言不合拜拜了，老板只能再招一个程序猿。这家伙一来，看完程序第一句话：xxxx！这tmd那个xxx写的啊！这得从头捋一遍啊。这个猿是个救世的主，捋清楚之后，把你写的吃饭，喝水，玩耍，睡觉等逻辑各自封装到一个单独的方法中，然后又完成了打豆豆这个方法，在main（）方法中一调完事了，main（）方法的逻辑清晰多了。这就是单一职责，一个方法只完成单一逻辑功能的实现（单一职责适用于接口、类、方法）！

单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。

单一职责原则的定义是：应该有且仅有一个原因引起类的变更。

单一职责原则的好处：

● 类的复杂性降低，实现什么职责都有清晰明确的定义；

● 可读性提高，复杂性降低；

● 可维护性提高，可读性提高自然更容易维护了；

● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有         影 响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

单一职责适用于接口、类，同时也适用于方法；这里涉及到设计粒度的粗细，是程序员很难把控的。

所以，这个设计原则备受争议，存在争议之处在哪里呢？就是对职责的定义，什么是类的职责，以及怎么划分类的职责（粒度粗细的控制）。

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

单一职责原则在真实项目中很难实现。

对于单一职责原则，本书的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

今天就写这么多了，希望对大家有所帮助，欢迎关注后续文章，谢谢！