我用过的设计模式（1）-- 本门心法

文章目录

单一职责原则

什么是“单一职责原则”？

饱受争议的原则

“单一职责原则”的优势

怎么用？自己看着办

里氏替换原则

什么是“里氏替换原则”？

关于里氏替换原则

依赖倒置原则

什么是“依赖倒置原则”

关于依赖倒置原则的小故事

依赖倒置，让项目并驾齐驱

最佳实践

接口隔离原则

什么是“接口隔离原则”？

接口要高内聚

最佳实践

迪米特法则

松耦合的法则：迪米特法则

开-闭原则

何为“开闭原则”

如何应对需求变化？

单一职责原则

什么是“单一职责原则”？

如果要理解为：一个类只有一个职责，当然也是可以的，简单化嘛。

单一职责的原话解释是这样的：There should never be more than one reason for a class to change.

什么意思？那里，应该，没有，多于，一个，原因，使得，类，去，改变。

啊，咱这蹩脚英语，勉强能翻译啊。

不过，能看懂是一回事，具体实现就是另一个故事了。。。

饱受争议的原则

为什么饱受争议呢？看着多单纯一原则啊。

这样，我们来看一个打电话的过程：

class 电话{

public:

void 拨出电话(string 电话号码);

void 瞎比比(Object *哔哔类对象); //总不能传个string吧，说一句就没啦？

void 挂电话();

}；

这个有没有问题？是有那么小问题的嘞。

你说我哪天，拨号的方法要改一下，我变成拨不通就一直拨，那这个类变一下。

然后我通信的方法再改一下，我现在不允许两个人同时说话，一个说完另一个再说，那这个类再变一下。

这个类，有两个职责：协议管理和数据传送。

那怎么搞？把那俩接口独立出来呗，然后将两个职责融合在一个类中。

现在变成了一个类融合了两个接口，确实那个实现类还是有两个原因引起变化，但是别忘了，我们是面向接口编程（后面会提到，依赖倒置原则）。我们对外公布的是接口，又不是实现类。

如果你非要对这个栗子实现单一原则，也可以，你要有那个权力或精力（因为我估计没人愿意陪你这样玩）。

“单一职责原则”的优势

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

这是最首要的，如果不能降低复杂度，那就别分开

可读性提高

可维护性提高

变更引起的风险降低

怎么用？自己看着办

对于接口，我们在实现的时候一定要做到单一

，但是对于实现类就需要多方面考虑了。

生搬硬套的话会有什么不良反应，去试试就知道了。

单一职责很难在项目中得到体现，就拿上面那栗子来说，能把接口分开就谢天谢地吧。

当然，单一职责也可以用于类方法，说来惭愧，我曾经用一个类方法实现五个功能（通过巧妙设置参数）。。。。

现在想想，真是好笑啊。

里氏替换原则

什么是“里氏替换原则”？

这个原则，说简单也简单，说拗口也拗口。

是这样说的：Function that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

所有引用基类的地方，必须能透明的使用其子类对象。

什么意思呢？就是子类必须实现父类的所有方法。有父类出现的地方，子类就可以出现。

关于里氏替换原则

关于里氏替换原则，我并不想讲太多，无非就是父类弄成纯虚基类，然后客端调用的时候以子类来new出父类声明的对象：父类 * 对象 = new 某子类();

这种格式后面会常见，见到的时候自然就明白了。

依赖倒置原则

什么是“依赖倒置原则”

这是我最喜欢的一个原则，也是受益最大的。

它的定义是：High level modules should not depend upon low level modules. Both should depend upon abstractions. Absteactions should not depend upon details.Details should depend upon abstractions.

高层模块不应该依赖于低层模块，二者都应该依赖于抽象。

抽象不应该依赖于细节。

细节应该依赖于抽象。

关于依赖倒置原则的小故事

故事是别人的，不过放在这里也是很应景啦。

故事是这样的：

有个适龄小伙子，他还单着。有一天，他喜欢的那个姑娘突然给他打电话，说她的电脑坏了，一用就蓝屏警告。姑娘讲着讲着就要哭出来了，小伙子那个急啊，他心疼啊。所幸，小伙子凭借高超的技术，当机立断：内存条坏了。但是又苦于所爱隔山水啊，所以他只能当远程指挥官了。他指导姑娘：扒开电脑主机后盖，把内存条扯出来，然后开机看看，如果还蓝屏，那就把那条内存条插回去，把另一条拔出来。一顿操作猛如虎，姑娘在小伙无私又认真的指挥下，把电脑修好了。

过两天，姑娘又打电话给小伙子，说她收音机坏了，希望小伙能再远程指导一次。但是这次小伙无能了，他不行了，他不会，太难了。他放弃了，他把电话挂了。姑娘很失望。

但是姑娘不知道，电脑，是松耦合，强内聚的，哪个部件坏了就换哪个，但是收音机不一样，收音机是紧耦合的，牵一发而动全身，收音机没声音，可能是扩音器坏了，可能是信号接收其坏了，可能是解频罢工了···毕竟她是外行嘛，悲催的小伙子。

那么，就要切入到我们的正题了，松耦合、强内聚的电脑，是怎么组装的呢？

像内存条这种东西啊，管你是哪家生产的，只要符合规格，再比如鼠标、键盘、电池（电池得配套），反正哪个部件坏了就换哪个部件。为什么这些部件不论插在哪一台电脑上都能使用呢？是这些部件配合电脑主板设计，还是电脑主板配合这些零部件设计呢？

想来答案已经很明确了。就拿CPU来说，CPU的对外都是针脚式或触点式的标准接口，只要接口设计好，内部再复杂和外界也没有关系。哪个主板要插CPU，那就得和CPU的接口对上。那么这时候如果电脑的内存条坏了，就不该成为你更换麦克风的理由。这不是开玩笑，要是收音机的外放坏了，可能得整部收音机脱胎换骨了。

PC的接口始终是有限的，但是软件设计得好，却可以不断地拓展的。

依赖倒置，让项目并驾齐驱

我们来思考一下依赖倒置对并行开发的影响。

如果两个类之间有依赖关系，只要定制出两者之间的接口（或抽象类），就可以独立开发了。就像我最近做的一个图书管理项目，只要合理地运用依赖倒置，便可以很好的将界面与后台数据访问解耦合，从而实现并行开发。

最佳实践

依赖倒置原则的本质就是通过抽象使得各个类或模块的实现彼此独立，不互相影响，实现模块之间的松耦合，我们怎么在项目中使用这个规则呢？只要通过以下的几个规则：

每个类尽量都有接口或抽象类，或者抽象和接口二者都具备。

变量的表面类型尽量是接口或者抽象类。

任何类都不应该从具体类派生。

尽量不要覆写基类的方法。

结合里氏替换原则。

反正我以前是一条都没对上。

“依赖倒转原则”在小项目上很难体现出来。

接口隔离原则

什么是“接口隔离原则”？

它建立在“依赖倒置原则”之上，

它的定义有俩：

Client should not be forced to depend upon interfaces that they don’t use.

客户端不应该依赖于它不需要的接口。

The dependency of one class to another one should depend on the smallest possible interface.

类之间的依赖关系应该建立在最小的接口上。

简单易懂啊，如果对前面那个原则有一定的把握。

建立单一接口，接口尽量细化。

接口要高内聚

什么是高内聚？高内聚就是提高接口、类、模块的处理能力，减少对外的交互。比如说你告诉你的保镖，今天去给我买一打爱马仕，他就去了。你也不用问他花了多少钱，他也不用问你是不是抽风了，这种不问条件执行的行为就是高内聚。

接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也越大，同时也有利于降低成本。

最佳实践

- 一个接口只服务于一个子模块或业务逻辑 - 通过业务逻辑压缩接口中的public方法，接口要勤快点重构 - 已经被污染的接口，尽量去修改 - 了解环境，拒绝盲从

1

2

3

4

5

6

迪米特法则

松耦合的法则：迪米特法则

英文解释：Only talk to your immedate friends.

只与直接的朋友通信。

如果两个类之间不能直接通信，那么这两个类就不应该发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

迪米特法则首先强调在类的设计上，每一个类都应该尽量降低成员的访问权限，强调了类之间的松耦合。

类之间的耦合越弱，越有利于重复利用，一个处在弱耦合的类被修改，不会对相关类造成波及。

开-闭原则

何为“开闭原则”

Software entities like classes, modules and functions should be open for extension but closed for modifications.

一个软件实体，应该对拓展开放，对修改关闭。

抽象实体：

项目或软件产品中按照一定的逻辑规则划分的模块。 抽象类 方法

1

2

3

这个原则很重要，后面会很经常见。

多说无益，我就稍微说两句，后面慢慢看它真面目。

如何应对需求变化？

既然说，对修改要关闭，那需求变化了怎么办？

有如下方法：

1、修改接口 2、修改实现类 3、通过拓展实现变化

1

2

3

至于为什么需要这个原则、如何使用、何时使用这个原则，跟着我的步伐，往后看。

今天的分享到此告一段落，算是我回归设计模式模块的礼物。

软件开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。