设计原则

设计原则

2017-11-18 今天周一呢 今天周一呢

在接下来的1-2月的时间里，我将会和大家一同学习设计模式之禅这本书，这本书一共包括“六大心法，23种武林招式”，也就是六大设计原则和23种设计模式，希望能对你有帮助。

话不多说，赶快上车！

---

一、Single Responsibility Principle(SRP)单一职责原则

对SRP 解释的原话是：

There should never be more than one reason for a class to change.

意译就是：应该有且只有一个原因引起类的变更。

文中作者举了一个例子：一个电话应该至少包含三个功能：拨号、通话、挂断。

如果写一个接口的话就是:

public interface Phone{      //拨号      public void dial(String phoneNumber);      //通话      public void chat(Object o);      //挂断      public void hangup();}

这个接口看起来没有任何问题，但却不符合SRP，应该有且仅有一个原因引起类的变更，也就是一个类或接口只有一个职责。然而这个类却包含的两个职责：

a、协议管理（接通或挂断）

b、数据传送（通信）

如果协议变化则会影响到这个类，而数据传输发生变化也会影响到这个类。这样就有了两个原因都引起的类的变化，也就违背了单一职责原则。接下来我们做些修改，将这个接口分为两个接口：

这个类图看起来有点复杂，却完全满足了单一指责原则的要求，每个接口职责分明，功能清晰，但是一个手机要把两个类组合起来才能使用，组合是一种强耦合关系，两个类有共同的生命周期，而在软件设计中强调要遵循“高内聚，低耦合”，所以需要再次改进。

一个类实现了两个接口，把两个职责融合到了一个类中，可能你会问，这样不还是有两个原因引起类的变化了啊。的确是这样，但是不要忘记我们时面对接口编程。我们对外公布的是接口，而不是实现类。

通过上面的例子大致的了解了SRP原则，那我们就来总结下SRP的优点：

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

b、可读性提高，复杂性降低，

c、可维护性提高，因为可读性提高了当然可维护性就高了

d、变更的风险降低，变更是必不可少的，如果接口的职责单一，一个接口修改只影响到对应的实现类，对其他的接口不产生影响，这对系统的扩展性和维护性都有非常大的帮助。

然而SRP这个设计模式是最具争议的，如果你想和别人争吵这个原则是屡试不爽。因为不同人对职责的划分是不同的。然而在设计类的时候，经常会违背单一原则，并且都有违背的理由。有很多人都用这句话来解释：

This is sometimes hard to see

翻译过来就是：这有时候很难说。

因为设计类有很多其他的因素制约，例如项目工期、成本、人员技术水平、硬件情况等，单SRP原则是很优秀的，但实现起来会有一定的难度。而作者建议接口一定要做到单一职责，类的设计尽量遵循只有一个原因引起变化。

---

本系列的文章会持续更新大概一两个月

记得长按下面的二维码添加关注哦

如果有问题欢迎在公众号内直接留言