设计模式定义以及合理使用注意事项

---

设计模式

一、定义

设计模式（pattern）是从许多优秀的软件系统中总结出的成功的可复用的设计方案。

软件模式：

•对通用设计问题的重复解决方案

•对真实世界问题的实践的/具体的解决方案

•面向特定的问题环境

•权衡利弊之后得到的“最佳”解决方案

•领域专家和设计老手的“杀手锏”

•用文档的方式记录的最佳实践

•在讨论问题的解决方案时，一种可交流的词汇

•在使用（重用）、共享、构造软件系统中，一种有效地使用已有的智慧/经验/专家技术的方式

二、记录要素

记录一个设计模式需有四个基本要素：

1．名称 一个模式的名称高度概括该模式的本质，有利于该行业统一术语、便于交流使用。

2．问题 描述应该在何时使用模式，解释设计问题和问题存在的前因后果，描述在怎样的环境下使用该模式。

3．方案 描述设计的组成部分，它们之间的相互关系及各自的职责和协作方式。

4．效果 描述模式的应用效果及使用模式应当权衡的问题。主要效果包括使用模式对系统的灵活性、扩充性和复用性的影响。

例如，GOF之书如下记录中介者模式：

名称 中介者

问题 用一个中介者来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

方案 中介者（Mediator）接口、具体中介者（ConcreteMediator）、同事（Colleague）、具体同事（ConcreteColleague）。

效果 减少了子类的生成、将各个同事解耦、简化了对象协议、控制集中化。

三、合理使用模式

不是软件的任何部分都需要套用模式来设计的，必须针对具体问题合理的使用模式。

1. 正确使用

当你设计某个系统，并确认所遇到的问题刚好适合使用某个模式，就可以考虑使用该模式到你的系统设计中，毕竟该模式已经被公认是解决该问题的成功方案，能使设计的系统易维护、可扩展性强、复用性好，而且这些经典的模式也容易让其他开发人员了解你的系统和设计思想。

2. 避免教条

模式不是数学公式、也不是物理定律、更不是软件设计中的“法律”条文，一个模式只是成功解决某个特定问题的设计方案，你完全可以修改模式中的部分结构以符合你的设计要求。

3.模式挖掘

​ 模式不是用理论推导出来的，而是从真实世界的软件系统中被发现、按着一定规范总结出来的可以被复用的方案。许多文献或书籍里阐述的众多模式实际上都是GOF书中经典模式的变形，这些变形模式都经过所谓的“三次规则”，即该模式已经在真实世界的三个方案中被成功的采用。可以从某个系统中洞察出某种新模式，只要经过“三次规则”就会被行业认可。

4.避免乱用

​ 不是所有的设计中都需要使用模式，因为模式不是发明出来的，而是总结出来的，事实上，真实世界中的许多设计实例都没有使用过GOF之书中的经典模式。在进行设计时，尽可能用最简单的方式满足系统的要求，而不是费尽心机地琢磨如何在这个问题中使用模式，一个设计中，可能并不需要使用模式就可以很好地满足系统的要求，如果牵强地使用某个模式可能会在系统中增加许多额外的类和对象，影响系统的性能，因为大部分设计模式往往会在系统中加入更多的层，这不但增加复杂性，而且系统的效率也会下降。

5.了解反模式

• 所谓反模式就是从某些软件系统中总结出的不好的设计方案，反模式就是告诉你如何采用一个不好的方案解决一个问题。既然是一个不好的方案，为何还有可能被重复使用呢？这是因为，这些不好的方案表面上往往有很强的吸引力，人们很难一眼就发现它的弊端，因此，发现一个反模式也是非常有意义的工作。在有了一定的设计模式的基础之后，你可以用搜索引擎查找有关反模式的信息，这对于学习好设计模式也是非常有帮助的。