网址引用：https://www.jb51.net/article/237927.htm
一、设计模式概述
设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
设计模式其实就是开发过程中常见问题的解决方案，是解决问题的思路。学习设计模式能更优雅的解决面向对程序开发设计问题。
二、面向对象23种设计模式
创建型模式
关注对象的创建
| 模式名称 | 中文名称 | 基本定义 |
|---|---|---|
| Singleton | 单例模式 | 保证一个类仅有一个实例，并且提供一个全局访问点。 |
| Factory Method | 工厂方法模式 | 定义一个用于创建对象的接口，让子类决定将哪一个类实例化。工厂方法模式使一个类的实例化延迟到子类。 |
| Abstract Factory | 抽象工厂 | 提供一个创建一系列相关或相互依赖对象的接口，而无需指定具体的类。 |
| Builder | 建造者模式 | 讲一个复杂对象的构建和他的表示分离，使得同样的构建过程可以创建不同的表示 |
| Prototype | 原型模式 | 用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。 |
结构型模式
关注类与对象之间的组合
| 模式名称 | 中文名称 | 基本定义 |
|---|---|---|
| Adapter | 适配器模式 | 将一个类的接口转换成客户希望的另一个接口。适配器使得原来不兼容的接口可以一起工作。 |
| Bridge | 桥接模式 | 将抽象部分与它的实现部分分离，使他们都可以独立变化 |
| Composite | 组合模式 | 将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得客户对单个对象对单个对象和复合对象的使用具有一致性。 |
| Decorator | 装饰器模式 | 动态的给一个对象添加一些额外的职责。就扩展方式而言，装饰器模式比生成子类的方式更灵活 |
| Facade | 外观模式 | 为子系统的一组接口提供一个一致的界面，Facade模式定义了一个高层的接口，这个接口使得这一个子系统更容易使用。 |
| Flyweight | 享元模式 | 运用共享技术有效的支持大量细粒度对象。 |
| Proxy | 代理模式 | 为其他对象提供一个代理以控制对这个对象的访问。 |
行为型模式
关注对象和行为的分离
| 模式名称 | 中文名称 | 基本定义 |
|---|---|---|
| Interpreter | 解释器模式 | 给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的例子。 |
| Template Method | 模板方法模式 | 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤 |
| Chain of Responsibility | 职责链模式 | 为解除请求的发送者和接收者之间的耦合，而使多个对象都有机会处理这个请求。讲这些对象连着一个链，并沿着这条链传递该请求，直到一个对象处理它。 |
| Command | 命令模式 | 将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可取消操作。 |
| Iterator | 迭代器模式 | 提供一种方法顺序访问一个聚合对象中的各个元素，而又不需要暴露该对象的内部表示。 |
| Mediator | 媒介模式 | 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示的相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。 |
| Memento | 备忘录模式 | 在不破坏封装性的前提下，捕获一个对象的内部状态，并在这个对象之外保存这个状态。这样就可以将这个对象恢复到保存的状态。 |
| Observer | 观察者模式 | 定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新。 |
| State | 状态模式 | 允许一个对象在其内部状态改变时改变他的行为。对象看起来似乎修改了他所属的类。 |
| Strategy | 策略模式 | 定义一系列算法，把它们一个个封装起来，并且使他们可相互替换，本模式使得算法的变化可独立于他的客户 |
| Visitor | 访问者模式 | 表示一个作用于某对象结构的各元素的操作。他使你可以在不改变元素的类的前提下定义作用于这些元素的操作 |
三、设计模式六大原则详细解析
- 单一职责：一个类只负责一 项职责
- 里氏替换原则：子类可以扩展父类的功能，但不能改变原有父类的功能。尽量用子类替换父类
- 依赖倒置原则：抽象不应该依赖于细节，细节应当依赖于抽象，面向接口编程
- 接口隔离原则：使用多个专门的接口，而不使用单一的总接口。即 客户端不应该依赖于那些它不需要的接口
- 迪米特原则：最少知道原则，尽量降低类与类之间的耦合；一个对象应该对其他对象有最少的了解
- 开闭原则：对扩展开放，对修改关闭，能扩展不修改
四、源码仓库
标签：23,C#,子类,接口,对象,模式,一个,设计模式 来源： https://www.cnblogs.com/bruce1992/p/16435230.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。