# DesignPattern
**Repository Path**: dolayout/DesignPatternOfCSharp
## Basic Information
- **Project Name**: DesignPattern
- **Description**: DesignPattern GoF 23+1 | 设计模式 23+1
- **Primary Language**: C#
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: https://blog.csdn.net/chaitsimplelove/category_7688479.html
- **GVP Project**: No
## Statistics
- **Stars**: 1
- **Forks**: 0
- **Created**: 2021-03-05
- **Last Updated**: 2023-04-25
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
# DesignPattern
#### DesignPattern GoF 23+1 | 设计模式 23+1
### 一、根据目的来分；通过完成什么工作划分为创建型模式、结构型模式和行为型模式 3 种类型
1. 创建型模式：作用于对象的创建，将对象的创建与使用分离。其中囊括了单例、原型、工厂方法、抽象工厂、建造者 5 种创建型模式。
2. 结构型模式：将类或对象按某种布局组成更大的结构，其中以代理、适配器、桥接、装饰、外观、享元、组合 7 种结构型模式为主。
3. 行为型模式：作用于类或对象之间相互协作共同完成单个对象无法单独完成的任务，以及怎样分配职责。主要包含了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。
#### （一）创建型的设计模式：
- 单例模式(Singleton) =》确保有且只有一个对象被创建。
- 构建模式(Builder) =》
- 原型模式(Prototype) =》
- 抽象工厂模式(Abstract Factory) =》允许客户创建对象的家族，而无需指定他们的具体类。
- 工厂方法模式(Factory Method) =》由子类决定要创建的具体类是哪一个。
#### （二）行为设计模式：
- 策略模式(Strategy) =》
- 状态模式(State) =》
- 责任链模式(Chain of Responsibility) =》
- 解释器模式(Interpreter) =》
- 命令模式(Command) =》
- 观察者模式(Observer) =》
- 备忘录模式(Memento) =》
- 迭代器模式(Iterator) =》
- 模板方法模式(Template Method) =》
- 访问者模式(Visitor) =》
- 中介者模式(Mediator) =》
#### （三）结构型设计模式：
- 装饰者模式(Decorator) =》
- 代理模式(Proxy) =》
- 组合模式(Composite) =》
- 桥连接模式(Bridge) =》
- 适配器模式(Adapter) =》
- 蝇量模式(Flyweight) =》
- 外观模式(Facade) =》
### 二、根据作用范围来分；根据是用于类上还是用于对象上划分分为类模式和对象模式两种。
1. 类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，在编译时刻便确定下来了。工厂方法、（类）适配器、模板方法、解释器均属于该模式。
2. 对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。除了以上 4 种，其他的都是对象模式。
https://img2018.cnblogs.com/i-beta/1733497/202001/1733497-20200116153415575-1321038090.png
### 三、根据功能划分；
https://img2018.cnblogs.com/i-beta/1733497/202001/1733497-20200116153914574-1425859506.png
### 四、面向对象设计原则
- 开闭原则：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。
* 作用：
1. 方便测试；测试时只需要对扩展的代码进行测试。
2. 提高代码的可复用性；粒度越小，被复用的可能性就越大。
3. 提高软件的稳定性和延续性，易于扩展和维护。
* 实现方式：通过“抽象约束. 封装变化”来实现开闭原则。通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类。
- 里氏替换原则：继承必须确保超类所拥有的性质在子类中仍然成立。子类可以扩展父类的功能，但不能改变父类原有的功能。
* 作用：
1. 克服了继承中重写父类造成的可复用性变差的缺点。
2. 保证了动作正确性。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。
* 实现方式：继承，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
- 依赖倒置原则：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。其核心思想是：要面向接口编程，不要面向实现编程。
* 作用：
1. 依赖倒置原则可以降低类间的耦合性。
2. 依赖倒置原则可以提高系统的稳定性。
3. 依赖倒置原则可以减少并行开发引起的风险。
4. 依赖倒置原则可以提高代码的可读性和可维护性。
* 实现方式：
1. 每个类尽量提供接口或抽象类，或者两者都具备。
2. 变量的声明类型尽量是接口或者是抽象类。
3. 任何类都不应该从具体类派生。
4. 使用继承时尽量遵循里氏替换原则。
- 单一职责原则：一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。核心就是控制类的粒度大小. 将对象解耦. 提高其内聚性
* 作用：
1. 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
2. 提高类的可读性。复杂性降低，自然其可读性会提高。
3. 提高系统的可维护性。可读性提高，那自然更容易维护了。
4. 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。
- 接口隔离原则：客户端不应该被迫依赖于它不使用的方法，一个类对另一个类的依赖应该建立在最小的接口上
* 作用：
1. 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
2. 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
3. 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
4. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
5. 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。
* 实现方式：
1. 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
2. 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
3. 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
4. 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
- 迪米特法则：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，通过第三方转发调用降低类之间的耦合度，提高模块的相对独立性
* 作用：
1. 降低了类之间的耦合度，提高了模块的相对独立性。
2. 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。
* 实现方式：
- 合成复用原则：在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
* 作用：
1. 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
2. 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
3. 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。
* 实现方式：将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。
总结：
* 对于7种设计原则其各自的侧重点不同。
* 其中，开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭；
* 里氏替换原则告诉我们不要破坏继承体系；
* 依赖倒置原则告诉我们要面向接口编程；
* 单一职责原则告诉我们实现类(方法)要职责单一；
* 接口隔离原则告诉我们在设计接口的时候要精简单一；
* 迪米特法则告诉我们要降低耦合度；
* 合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。