Go-设计模式
2022-11-24 / 可可西里
设计模式是软件工程中各种常见问题的经典解决方案，设计模式不只是代码，而是组织代码的方式。假设一行行的代码是砖，设计模式就是蓝图
类型 |
设计模式 |
简述 | 常用 |
|---|---|---|---|
| 创建型 | 工厂模式 | 定义一个创建对象的接口，让其子类自己决定范例化哪一个工厂类，是最常用的设计模式之一 | yes |
| 抽象工厂模式 | 为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构 | yes | |
| 建造者模式 | 将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示。它是将一个复杂的对象分解为多个简单的对象，然后一步一步构建而成 | yes | |
| 原型模式 | 用一个已经创建的范例作为原型，通过复制该原型对象来创建一个和原型相同或相似的新对象 | no | |
| 单例模式 | 保证一个类仅有一个范例，并提供一个访问它的全局访问点单例模式只涉及到一个类，该类负责创建自己的对象，而且确保只有单个对象被创建 | yes | |
| 结构型 | 适配器模式 | 将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作 | yes |
| 桥接模式 | 将抽象与实现分离，使两者可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度 | yes | |
| 组合模式 | 对象树模式/整体-部分模式。将对象组合成树状的层次结构的模式，用来表示“整体-部分”的关系，使用户对单个对象和组合对象具有一致的访问性 | no | |
| 装饰器模式 | 动态地给一个对象添加一些额外的职责。允许向一个现有的对象添加新的功能，同时又不改变其结构 | yes | |
| 外观模式 | 又称为门面模式，它为子系统中的接口提供一个一致的接口，来隐藏子系统内部的复杂性，使得子系统更加容易使用 | no | |
| 享元模式 | 运用共享技术有效地支持大量细粒度的对象，减少对象的创建数量，以节省内存占用和提高性能 | no | |
| 代理模式 | 由于某些原因需要为某对象提供一种代理以控制对该对象的访问当访问对象不适合或者不能直接引用目标对象的时候，可以通过代理对象作为访问对象和目标对象之间的中介 | yes | |
| 行为型 | 责任链模式 | 为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止 | yes |
| 命令模式 | 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作 | no | |
| 迭代器模式 | 提供了一种方法顺序访问一个聚合对象中的所有元素，而又不暴露该聚合对象的内部表示用于顺序访问集合对象的元素，调用者无需知道集合对象的底层表示，从而实现调用者和聚合对象的解耦 | yes | |
| 中介者模式 | 用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护 | no | |
| 备忘录模式 | 保存一个对象的某个状态，以便在适当的时候恢复对象 | no | |
| 观察者模式 | 定义了对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新 | yes | |
| 状态模式 | 对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为 | yes | |
| 策略模式 | 通过定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户 | yes | |
| 模板方法模式 | 定义一个操作中的算法骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构,即可重定义该算法的某些特定步骤 | yes | |
| 访问者模式 | 将作用于某种数据结构中的各元素的操作分离出来封装成独立的类，使其在不改变数据结构的前提下可以添加作用于这些元素的新的操作，为数据结构中的每个元素提供多种访问方式。它将对数据的操作与数据结构进行分离，是行为类模式中最复杂的一种模式 | no |
1. 工厂模式
问题
解决
2. 抽象工厂模式
问题
解决
3. 建造者模式
问题
解决
4. 原型模式
问题
解决
5. 单例模式
问题
解决
6. 适配器模式
问题
解决
7. 桥接模式
问题
解决
8. 组合模式
问题
解决
9. 装饰器模式
问题
解决
10. 外观模式
问题
解决
11. 享元模式
问题
解决
12. 代理模式
问题
解决
13. 责任链模式
问题
解决
14. 命令模式
问题
解决
15. 迭代器模式
问题
解决
16. 中介者模式
问题
解决
17. 备忘录模式
问题
解决
18. 观察者模式
问题
解决
19. 状态模式
问题
解决
20. 策略模式
问题
解决
21. 模板方法模式
问题
解决
22. 访问者模式
问题
解决
23. 设计模式的“道”
设计模式分为“术”的部分和“道”的部分，上面那些设计模式就是“术”的部分，他们是一些围绕着设计模式核心思路的经典解决方案。换句话说，重要的是理解为什么要用那些设计模式，具体问题，具体分析，而不是把某种设计模式生搬硬套进代码
设计模式有6大原则，以上的设计模式目的就是为了使软件系统能达到这些原则：
- 开闭原则
- 软件应该对扩展开放，对修改关闭
- 对系统进行扩展，而无需修改现有的代码。这可以降低软件的维护成本，同时也增加可扩展性
- 里氏替换原则
- 任何基类可以出现的地方，子类一定可以出现
- 里氏替换原则是对开闭原则的补充，实现开闭原则的关键步骤就是抽象化，基类与子类的关系就是要尽可能的抽象化
- 依赖倒置原则
- 面向接口编程，抽象不应该依赖于具体类，具体类应当依赖于抽象
- 这是为了减少类间的耦合，使系统更适宜于扩展，也更便于维护
- 单一职责原则
- 一个类应该只有一个发生变化的原因
- 一个类承载的越多，耦合度就越高。如果类的职责单一，就可以降低出错的风险，也可以提高代码的可读性
- 最少知道原则
- 一个实体应当尽量少地与其他实体之间发生相互作用
- 还是为了降低耦合，一个类与其他类的关联越少，越易于扩展
- 接口分离原则
- 使用多个专门的接口，而不使用高耦合的单一接口
- 避免同一个接口占用过多的职责，更明确的划分，可以降低耦合。高耦合会导致程序不易扩展，提高出错的风险
编程宝库链接：点击跳转
掘金链接：点击跳转
华为云链接：点击跳转
本文链接：
https://huajun-chen.github.io/2022/11/24/Go-设计模式/