前言背景

　　这是一条望不到尽头的编程之路，自踏入编程之路开始。就面临着各式各样的挑战，而我们也需要不断的挑战自己、不断学习充实自己、打好坚实的基础。以使我们可以走的更远。刚踏入编程的时候。根据需求编程，需求改代码改。需求加代码加。重复来重复去。一切都觉得还不错。功能实现了，项目跑起来了。但是真的就不错了吗？当然不是，也许过了几年你再回头看这些代码或许你也不知道写的啥了。这样写出来的代码你自己都可能看不到，更何况其他人呢？对吧。偶尔一次闯入一处秘境。发现了一本名叫”设计模式”的”武功”秘籍。也是编程之路之上不可获取的能力之一。它解决了代码重复使用，代码冗余的问题。使代码结构简洁易懂。使代码的思路清晰明了。代码优美，结构完善合理。我们一起看看这个至高的秘籍。

关卡模式详细介绍

　　下面我们看看此秘籍具体到底有些啥。放心、绝对不会像那啥”欲练神功必先自宫”一般的秘籍了。

　　此本秘籍分为三大部分：

一、创建型模式

二、结构型模式

三、行为型模式

　　第一部分的创建型模式共分为：

第一章　单例模式（Singleton）

保证一个类仅有一个实例，全局调用。该模式是将对象创建的数量控制为一个。

第二章　工厂方法模式（Factory Method）

工厂模式讲究的是一个工厂对应一个产品的模式，平行的等级结构，这里重点针对”单个对象”的变化

第三章　抽象工厂模式（Abstract Factory）

抽象工厂模式关注的更多是多系列的或相互依赖的产品变化，提供一个创建一系列相关或相互依赖对象的接口，无需指定它们的类。

第四章　建造者模式（Builder）

该模式解决的主要是”一个复杂对象”的创建工作的问题，各个子对象组合一个复杂对象。组合的算法稳定，子对象易变化的情况

第五章　原型模式（Prototype）

通过原型实例来创建对象，然后通过拷贝原型来创建新对象

第二部分的结构型模式共分为：

第六章　适配器模式（Adapter）

该模式主要关注的是接口转换的问题，将匹配的接口通过适配对接工作

第七章　桥接模式（Bridge）

该模式关注的是分离接口与其具体实现，使其变化独立

第八章　装饰模式（Decorator）

该模式关注的是动态的给对象增加一些额外的职责，稳定接口不变。此模式比生成子类继承更加的灵活

第九章　组合模式（Composite）

将对象组合成树形结构以表示“部分-整体”的层次结构，它使得客户对单个对象和复合对象的使用具有一致性。

第十章　外观模式（Facade）

该模式关注的是简化接口，简化组件系统与外部程序的依赖关系。

第十一章　享元模式（Flyweight）

该模式注重保留接口，在内部使用共享技术对对象存储进行优化

第十二章　代理模式（Proxy）

对其他对象提供一种对象来控制对这个对象的访问。

第三部分的行为型模式共分为：

第十三章　模版方法模式（Template Method）

该模式关注对算法结构的封装，定义稳定的算法结构，但是支持允许算法子步骤的变化。

第十四章　命令模式（Command）

将一个请求封装为一个对象，从而使你可用不同的请求对客户（客户程序，也是行为的请求者）进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。命令模式的实现可以提供命令的撤销和恢复功能。

第十五章　迭代器模式（Iterator）

提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。

第十六章　观察者模式（Observer）

定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。

第十七章　中介者模式（Mediator）

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

第十八章　状态模式（State）

允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。

第十九章　策略模式（Strategy）

定义一系列算法，把它们一个个封装起来，并且使它们可互相替换。该模式使得算法可独立于使用它的客户而变化。

第二十章　职责链模式(责任链模式—Chain of Responsibility)

避免请求发送者与接收者耦合在一起，让多个对象都有可能接受请求，将这些对象连接成一条链，并且沿着这条链传递请求，知道有对象处理它为止。

第二十一章　访问者模式（Visitor）

表示一个作用于某对象结构中的各个元素的操作。它可以在不改变各元素的类的前提下定义作用于这些元素的新的操作。

第二十二章　备忘录模式（Memento）

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。

第二十三章　解释器模式（Interpreter）

给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。

　　设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

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

闯关必备条件

　　话说之前有讲到面向对象三大特性——封装、继承、多态。也有讲到面向对象设计SOLID五大原则。今天我们也将开启设计模式的闯关之路。其中到底有没有联系呢？到底有没有关系呢？

　　事实上面向对象三大特性在一定程度上提现了面向对象设计的五大原则。那么与设计模式又有什么关系你。其实面向对象设计的五大原则也可称为设计模式五大原则。学习设计模式之前我们都得先了解其原则，学习期基础。在此基础之上学习设计模式才是最好的。

　　这里再次简单介绍设计模式的五大原则（SOLID）：

一、单一责任原则（SRP）

单一责任原则指出当需要修改某个类的时候原因有且只有一个。也就是说一个类应该只负责一件事情。

二、开放封闭原则（OCP）

开放封闭原则指的是程序模块应该遵循关闭修改，开放扩展。

三、里氏替换原则（LSP）

子类型必须可替代其基类型 –一个对象出现的地方都可以由其子类代替并且不会出错，即是符合里氏替换原则的。

四、接口分离原则（ISP）

接口分离原则—client不应该被强迫依赖它不使用的方法，表明方法是分开或者隔离的。

五、依赖倒置原则（DIP）

依赖倒置原则-也是最后一个原则了。其原则指出—一个高级模块不应依赖于低级模块，两个都应该取决于抽象。抽象不应该依赖具体细节，细节应该依赖于抽象。

总结开启闯关之路

　　打好基础，学习了解其设计的原则，学习设计模式必须在其原则的基础上学习。学习设计模式的路并不平稳，在起初之期，比较多的概念规则都不是很清楚、基础不扎实。会给学习之路带来诸多麻烦。学习理解之后我们也需要更多的思考。选择合适的设计模式使用，宁可不用、切勿乱用。用的好那么皆大欢喜普天同乐。可是用不好的话也有可能下一个祭天的就是你了。设计模式需要许多的模式实践。接下来的时间之中我们即将开启C#设计模式的闯关之路了。

　　生命不息、战斗不止!

欢迎大家扫描下方二维码，和我一起踏上设计模式的闯关之路吧!