前言：

很久没有写博客了，最近学习了很多东西，没有来得及总结，一直不写博客，慢慢的就有些懈怠了，现在正在学习设计模式，学习了一半，感觉设计模式就是将我混乱的程序让它变得思路清晰，虽然我还没达到这样的水平，但是这个是在于长久的实践练习，目前学习设计模式旨在认识一下都有哪些模式，体会其精髓，还得等到以后项目做多了，才能体会。我用的书是秦小波写的《设计模式之禅》，在图书馆翻到的书，喜欢这本书的风格，没有大量枯燥的语句，相反读这本书仿佛在和作者聊天，幽默风趣，而且讲解的深浅得当，书里举的例子给我一个感觉：生活中处处是对象啊……

打算是每天一个设计模式，包括书中对每个设计模式的扩展应用，现在先从6大原则入手，设计模式关键是理解其中的思想，要会画各种类图，编写代码是其次，所以督促自己不能偷懒啊，在这里记下笔记，希望以后能够用到。设计模式的学习，可能要用一个多月的时间，唉，真是有点对不住GOF，这么经典的模式，竟然要一天解决一个，放心，现在我只是粗略，但是对于设计模式的学习体会，绝对不会止步于此！

今天就先来看设计模式的第一个原则：单一职责原则（Single Responsibility Principle），简称SRP

单一职责原则定义：应该有且仅有一个原因引起类的变更，即一个接口或是类只有一个职责，它就负责一件事情。

先来看一个糟糕的设计

可以看到IPhone这个接口有两个职责，一个是协议管理，一个是数据传送。dial()和hangup()两个方法实现的是协议管理，而chat()实现的是数据传送。如果是这样设计的话，当协议变化或者是数据传送的变化，都会影响到这个接口，那么就增加了程序的风险，显然不是一种好的设计。这个时候，我们就看到单一职责的好处了，我们可以把这个接口拆成两个接口，让一个接口负责协议管理，另一个接口负责数据传送，这样当一个职责发生变化时，就不会影响到另一个，增加了程序的健壮性。来看一下改进之后的类图：

一个类实现了两个接口，把两个职责融合在一个类中。虽然Phone这个类有两个职责，但是我们是面向接口编程，对外公布的是接口而不是实现类。单一职责不仅适用于接口和类，同样适用于方法，即一个方法尽量做一件事情。

小结：

单一职责比较难实现，因为“职责”没有一个量化的标准，到底一个类负责哪些职责？职责怎么细化？这些都要从实际出发，不能生搬硬套原则，原则是死的，就像毛爷爷当年在中国应用马克思主义一样，不能生搬硬套，要在我们现实情况的基础上去应用原则。

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