1.设计模式第一步-《设计模式从头到脚舔一遍-使用C#实现》

更新记录：
完成第一次编辑：2022年4月23日20:29:33。
加入小黄人歌曲：2022年4月23日21:45:36。

1.1 设计模式（Design Pattern）是什么

设计模式是理论、是前人的经验、解决问题的方法、是一种编码的方式。由The Gang of Four：Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides提出。第一次我看到设计模式解释的时候那真的是云里雾里，这TMD的说的啥玩意儿。

直到我学会了一两个设计模式，然后Get到有趣点了，才明白原来是这么回事。在现在的面向对象程序中：设计模式更多是指代码如何创建对象、如何组合对象、如何设置对象间交互。那么您可能会说了，还不简单吗，创建对象不就new一个事情嘛，对对对，说的对，但这里面有挺多的套路，很有意思，各种new的花样。通常网络上的大佬把如何创建对象的设计模式称为“创建型设计模式”。再来说组合对象，大概就是你把我包含起来，或者我把你包含起来，再或者我们都是平级，但负责的任务不同，再或者就是你当我爸爸我当儿子。通常网络上的大佬把如何组合对象的设计模式称为“结构型设计模式”。设置对象间的交互这个好理解，对象之间通过方法实现互相交互，那么方法怎么设计，方法放在哪里，这也是一个很有意思的话题，通常网络上的大佬把如何设置对象间交互称为“行为型设计模式”。

1.2 设计模式分类

所以上面的大段废话可以总结为，设计模式就是一种设计上的套路 ，可以分为三类套路：
“创建型设计模式”：关注如何创建对象。通过不同方式控制对象创建来避免对象创建时可能导致设计问题或者增加设计复杂度。
“结构型设计模式”：关注类与类之间的关系，关系有很多种。组合优于继承。
“行为型设计模式”：关注类和对象如何交互和分配职责。

还是没看懂吗，没事，直接跳到后面看代码，看完代码再回来看这些没味道的文字。

---

1.3 为什么需要设计模式（为什么需要设计套路）

前面我们说到：设计模式是一种套路。那么为什么需要套路？先来看首牛逼的网友写的诗：

城市套路深，我要回农村。农村路也滑，套路更复杂。
城市套路深，我要回农村。农村路也滑，人心更复杂。
城市套路深，我要回农村。农村道路远，套路更加险。
城市套路深，我要回农村。农村已整改，套路深似海。

发现问题没有？套路是无处不再的。只要你在，套路就在。那么程序设计中套路也不例外，即使你不需要，本质上代码写多了，也会自己无意中用到/碰到一些套路。从本质上来说：不是我们需要设计模式，而是慢慢的代码写多了总结出来的一种套路，用这种套路可以给自己带来好处，比如：甲方爸爸要把功能改来改去、甲方爸爸想花5毛钱就把功能做出来、甲方爸爸想把A项目的代码直接改改用在B项目。 但是要注意：设计模式不是万能的，设计模式并不能解决所有问题，无论使用解决方法，都有利弊，毕竟原则是死的，人是活的。比如：妹子说：“啊啊~不要啊”。难道就真的停下来？

1.4 继续干

介绍完设计模式基本描述，接下来还要继续推进面向对象原则+具体设计模式，说好的从头到脚舔一遍，那就一定从头到脚舔一遍。
先把汇总放在这，后面搞定了再回来看。

面向对象基本原则

她们分别是：
单一职责原则(SRP)： 只干好一件事。
开/闭原则(OCP)： 欢迎扩展拒绝修改。
里式提换原则（LSP）： 儿子代替父亲做事情。
接口隔离原则(ISP) ： 细化接口。
依赖倒置原则（DIP）： 面向抽象编程。
迪米特法则(LoD)： 减少类公开方法。

具体设计模式，她们分别是：

创建型设计模式

工厂模式（Factory Pattern）
工厂方法（Method Factory）
抽象工厂模式（Abstract Factory Pattern）
单例模式（Singleton Pattern）
建造者模式（Builder Pattern）
原型模式（Prototype Pattern）

创建型设计模式总结：

• 工厂模式就是用方法代替new来实例化对象的方式，目的是减少new带来的耦合关系。
• Singleton模式解决对象个数问题，现在更流行使用IOC容器的方式进行实现。其他创建型模式解决new带来的耦合问题。
• Factory Method、Abstract Factory、Builder模式都需要一个额外的工厂类来负责实例化对象，而Prototype模式通过原型(特殊的工厂)来克隆生成对象。
• 通常情况下，遇到易变的类型最初英语考虑Factory Method模式来处理，当类型变得复杂的时候再考虑使用（Abstract Factory、Builder、Prototype）模式。
• 工厂方法是将类的实例化延迟到工厂类的子类中完成，由子类来决定应该实例化哪一个类，对客户端来说，消除了对具体产品的依赖。
• 抽象工厂将相关关联或者相互依赖的对象提供一个统一的接口。
• 原型模式用于重复的创建一个包含大量公共属性或者初始化需要消耗大量资源的对象，是西安对象的自我复制，尽量将原型模式标记为sealed。尽量避免使用ICloneable接口。

结构型设计模式

适配器模式（Adapter Pattern）
桥接模式（Bridge Pattern）
过滤器模式（Filter、Criteria Pattern）
组合模式（Composite Pattern）
装饰器模式（Decorator Pattern）
外观模式（Facade Pattern）
享元模式（Flyweight Pattern）
代理模式（Proxy Pattern）

结构型设计模式总结：
Adaptor模式注重转换接口，将不匹配的接口进行适配。
Proxy模式侧重控制对象的访问。
Bridge模式注重接口与实现分离，支持多维度的变化。
Composite模式注重统一接口，将“一对多”的关系转为“一对一”的关系。
Decorator模式主要提接口的稳定，在此前提下灵活的为对象扩展功能。
Facade模式注重接口的简化，简化组件系统与外部客户程序的依赖关系。
Flyweight模式注重保留接口，增加间接层来实现灵活控制。

行为型设计模式

责任链模式（Chain of Responsibility Pattern）
命令模式（Command Pattern）
解释器模式（Interpreter Pattern）
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
备忘录模式（Memento Pattern）
观察者模式（Observer Pattern）
状态模式（State Pattern）
空对象模式（Null Object Pattern）
策略模式（Strategy Pattern）
模板模式（Template Pattern）
访问者模式（Visitor Pattern）

行为型设计模式总结：
Template Method模式封装算法结构，支持算法子步骤的变化。
Strategy模式注重封装算法，支持算法的变化。
State模式注重封装与状态相关的行为，支持状态的变化。
Memento模式注重封装对象状态的变化，支持状态的保存与恢复。
Mediator模式注重封装对象间的交互，支持对象交互的变化。
Chain Of Responsibility模式注重封装对象责任，支持责任的变化。
Command模式注重将请求封装为对象，支持请求的变化。
Iterator模式注重封装集合对象内部的结构，支持集合的变化。
Interpreter模式注重封装特定领域的变化，支持领域问题的频繁变化。
Observer模式注重封装对象通知，支持通信对象的变化。
Visitor模式注重封装对象操作变化，支持在运行时为类层次结构动态添加新的操作。

1.5 如何学习设计模式

掌握以下要点：
设计模式的名称（叫什么）
设计模式的原理（是什么）
设计模式解决的问题和使用场景（可以干嘛,在哪里干）
描述设计模式的如何解决问题（怎么干）
具体的代码实现（具体干）
项目中使用设计模式（创造价值）
总结交流

即：叫什么→是什么→可以干嘛→在哪里干→怎么干→具体干→创造价值→活用

使用模式的最好境界：不拘泥于模式。