设计模式的意义与23种常见模式介绍_设计模式及其作用

自从计算机诞生以来，生产效率大大的提高，尤其是微型计算机能够进入千家万户。让大众能够利用强大的计算资源，但是单纯的计算机硬件虽然能够提供机械强大的计算能力，但是要有效的利用这样的能力就需要用软件去操作，就像不同国家的人说着不同的语言，我们需要通过翻译才能够顺利沟通，同样计算机也需要明白人类需要它做什么事情，所以计算机对应的语言就叫做机器语言即一般来说的二进制编码。这是一种跟人类语言相差很大的语言，虽然能够轻松并且高效的被计算机识别，当时的情况是这样的，用户需要借助计算机来完成某项计算活动必须找到指定的编码人员，然后编码人员将对应的运算操作翻译成计算机指令编码（纸带卡片输入计算机系统），随着计算机的广泛应用，早期的计算机使用的高门槛阻碍了计算机的推广，因此出现了一些更加靠近人类能够识别的指令系统，例如汇编语言，汇编语言经过汇编器能够翻译成机器能够看懂的机器码，降低了计算机使用者的门槛，后来还出现了更加接近人类的高级语言，例如C语言（严格意义C语言算中级语言，手动管理内存），还有更加高级的Java语言。
面向对象分析（OOA）是更加贴近人类思维模式的编程语言，以Java C++ 为代表的面向对象语言（OOP）一直是现代软件开发的主流语言，由于相关历史原因（主要是获得开源社区的支持），由此延伸出的相关技术与工具也蓬勃发展。作为软件开发的重要环节，面向对象设计的重要性不言而喻，软件的构建过程本质上就是从现实世界抽象的过程，使用面向对象技术构建软件架构就是为一个系统开始规划轮廓，具体的细节应该可以灵活的变动或者是可以添加新的抽象组件与细节。面向对象设计要考虑具体的业务需求场景，但是在大量前人的实践面前，总结出了一套设计的规范，这些规范大量运用在一些优秀的架构中，更确切的说在大量的架构设计的结果发现很多设计是有一些共同点的，这些共同点被总结成精炼的思想，为了便于开发者交流，我们起名叫做设计模式。
软件被视为知识密集型产品，一个软件产品从用户需求到一个成熟稳定的产品最重要是在对需求的把握并作出良好的设计，抽象的事物往往是稳定的，从现实世界到软件世界的主要过程就是在于抽象出产品对应的实体，而软件架构即是这样的重要成果。架构往往分为业务架构和技术架构，业务架构需要懂得业务的人根据用户场景组织现有的产品形态，业务架构更多是需要人去组织并执行，技术架构也面临着一样的需求，但是技术架构往往面临的是各种产品与技术的衔接。技术与业务缺一不可，因此在软件抽象建模的过程中往往面临着的大的业务场景是不同的，但是在复杂的业务往往都具有很多相似的小的功能需求。独立出这些功能点，设计模式能够帮助我们在面临类似需求的场景作出专家级的解决方案，不用过多去重复的做出一些不太明确的设计。但是设计模式只是一个指导性规范，不会要求使用者强制使用，为了模式而模式而忽视业务场景，往往导致过度设计这是舍本逐末。如果以面向对象的思想看待软件产品，从具体到抽象，可以发现对应的层次是在实例 -> 类 -> 抽象类 -> 接口 -> 框架 -> 模式,越趋于抽象的东西也就愈加稳定，同理学习各种技术的态度也应该是学习它的本质，而不应该浮于表面，在学校就应该好好学习数据结构和操作系统原理、汇编原理等等课程，越靠近产品（例如web前端）各种技术迭代更新越快，而计算机通信的二进制传输，几十年都不会变化，linux内核虽然有更新，但是都是向下兼容，不会有太大的改动，考虑到linux应用的广泛因此学习linux相比追求新潮的技术是更加保值的。甚至曾经有人说道学习设计模式的最好方式就是“学习完就忘掉它”，我们看待设计模式应该抱着学习它本身的思想，而不应该拘泥于具体的案例。设计不仅仅要考虑到当前，大量的互联网应用的产生，很多情况下是不能预知未来的产品走向，很多时候软件的开端并没有明确的需求，因此我们需要作出具有前瞻性的系统设计，在极端的情况下“反模式”甚至在有的时候是最佳解决方案，这依赖于具体的业务场景。模式帮助我们节省设计的时间，作为一种比较标准的参考方案，提升设计的效率重点内容质量。
设计模式被明确的提出是上世纪90年代的《GOF可复用面向对象设计》，大名鼎鼎的四人帮的著作，文中明确的指出了大量存在于各个面向对象设计中的23种设计模式，这些模式被大量的实践并且证明是十分优秀的设计。本博客也将详细介绍这23种设计模式。接下来将以分五个章节讲解设计模式的相关内容，第一章节主要介绍了设计模式的起源以及设计模式的意义。
23种设计模式：
1、Abstract Factory (抽象工厂模式)
提供一个创建一系列产品或相互依赖对象接口无需指定具体的类。

2、Adapter (适配器模式)
将一个类的接口转换成客户希望的另一个接口，Adapter使原本由于接口不兼容而不能正常工作的类可以正常工作。

3、Bridge (桥接模式)
将抽象部分与实现部分分离，使它们可以独立变化。

4、Build (建造者模式)
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

5、Chaine of Responsibility (责任链模式)
为接触请求的发送者和接受者之间的耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条连传递该请求，知道有一个对象处理。

6、Command (命令模式)
将一个请求封装为一个对象，从而使可以用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可取消操作。

7、Composite (组合模式)
将对象组合成树形结构以表示 “部分-整体”的层次结构。它使得客户对单个对象和符合对象的使用具有一致性。

8、Decator (装饰模式)
动态地给一个对象添加一些额外的职责，就扩展功能而言，它比生成子类方式更加灵活。

9、Facade (外观模式)
为子系统中的一组接口提供一个一致的界面，Facade模式定义一个高层接口，这个接口使得这一子系统更加容易使用。

10、Factory Method (工厂方法模式)
定义一个创建对象的接口，让子类决定将哪一个类实例化。使一个类实例化延迟到子类。

11、Flyweight (享元模式)
运用共享技术有效支持大量细粒度对象。

12、Intecepter (解释器模式)
给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中句子。

13、Iterator (迭代器模式)
提供一种方法顺序访问一个聚合对象中各个元素而又不暴露该对象内部表示。

14、Mediator (中介者模式)
用一个中介对象来封装一系列对象交互，中介者使各对象不需要显示的相互引用，从而使得其耦合松散，而且可以独立的改变他们之间的交互。

15、Memento (备忘录模式)
在补破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可将该对象回复到保存的状态。

16、Observer (观察者模式)
定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新。

17、Prototype (原型模式)
用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。

18、Proxy (代理模式)
为其他对象提供一个代理以控制对这个对象的访问。

19、Singleton (单例模式)
保证一个类仅有一个实例，并提供一个访问它的全局访问。

20、State (状态模式)
允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎属于一个新的类。

21、Stratege (策略模式)
定义一系列算法，把他们封装起来，并且使它们可以相互替换，本模式使得算法的变化可以独立与使用它的客户端。

22、Template Method (模板方法模式)
定义一个操作中的算法骨架，而将一些步骤延迟到子类，Template Method使得子类可以不改变一个算法结构即可重新定义该算法某些特定步骤。

23、Visitor (访问者模式)
表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。