初识几个常用的设计模式

1 概述

1.1 概念

设计模式，是在某个不断出现的“情境(Context)”下，针对某个“问题”的某种“解决方案”：

“问题”必须是重复出现的，“解决方案”必须是可反复应用的；

“问题”包含了“一个目标”和“一组约束”，当解决方案在两者之间取得平衡，才是有用的模式；

设计模式不是法律准则，只是指导方针，实际使用时可以根据需要微调，只是要作好注释，以便他人清楚；

很多看似的新模式，实质上是现有模式的变体；

模式的选用原则：尽量用最简单的方式设计，除非为了适应未来确实可能的变化，才采用设计模式，因为设计模式会引入更多类更复杂的关系，不要为了使用模式而使用模式。

1.2 六大原则

将六大原则的英文首字母拼在一起就是SOLID（稳定的），所以也称之为 SOLID 原则。

1.2.1 单一职责原则(Single Responsibility Principle)

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

一个类只有一个职责，而不是多个职责耦合在一个类中（比如界面与逻辑要分离）。

1.2.2 开放封闭原则(Open Closed Principle)

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

对扩展开放，对修改关闭，使用接口和抽象类。

1.2.3 里氏替换原则(Liskov Substitution Principle)

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

确保父类可以出现的地方，子类一定可以出现，这是继承复用的基石。

1.2.4 最少知道原则(Least Knowledge Principle)

Only talk to you immediate friends.

低依赖，各实体尽量独立，尽量减少相互作用。

1.2.5 接口隔离原则(Interface Segregation Principle)

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

客户(client)应该不依赖于它不使用的方法。尽量使用多个接口分工合成，而不是单个接口耦合多种功能。

1.2.6 依赖倒置原则(Dependency Inversion Principle)

High level modules should not depends upon low level modules.

Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.

要依赖于抽象（接口或抽象类），而不是具体（具体类）。

1.3 价值

设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

设计模式看似简单问题复杂化。但“简单”的设计灵活性差，在当前项目中不便扩展，拿到其他项目更是无法使用，相当于“一次性代码”。而设计模式的代码，结构清晰，当前项目中便于扩展，拿到其他项目也适用，是通用的设计。

很多程序员接触到设计模式之后，都有相见恨晚的感觉，感觉自己脱胎换骨，达到了新的境界，设计模式可以作为程序员划分水平的标准。

不过我们也不能陷入模式的陷阱，为了使用模式而去套模式，那样会陷入形式主义。

1.4 选用方法

每个设计模式，都隐含了几个OO原则，当没有合适的设计模式可选时，可回归到OO原则来取舍；

使用模式最好的方式：脑子里装着各种模式，看已有设计或代码中，哪里可以使用这些模式，以复用经验；

共享设计模式词汇(包括口头叫法、代码中类与方法的命名)的威力：

(1)与他人沟通时，提到设计模式名称，就隐含了其模式；

(2)使用模式观察软件系统，可以保持在设计层次，而不会被停留在琐碎的对象细节上；

(3)团队间用设计模式交流，彼此看法不容易误解。