设计模式学习笔记 - 水阙

[giscus[bot]]

设计模式学习笔记 - 水阙

如无特殊声明：本文所有 UML 图均出自《图说设计模式》。在此特别鸣谢！ Singleton 单例模式解决了全局变量的问题，全局只能创建一个实例，保证任何请求该实例的调

https://blog.yychi.website/post/design-pattern-notes/

[guyueshui]

Factory method 使用场景

1. 当子类型可能会有很多，以后需要不断增加不同的子类实现时；
2. 当一个系统尚在框架设计阶段，还不知道将来需要实例化哪些具体类时；
3. 系统设计之初不需要具体对象的概念（或者说没有具体对象的概念）；
4. 在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；
5. 在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。

[guyueshui]

Abstract factory 使用场景

1. 创建产品家族，相关产品集合在一起使用的时候；
2. 想要提供一个产品类库，并只想显示其接口而不是实现时；
3. 通过组合的方式使用工厂时；
4. 系统中有多于一个的产品族，而每次只使用其中某一产品族。可以通过配置文件等方式来使得用户可以动态改变产品族，也可以很方便地增加新的产品族；
5. 属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。同一个产品族中的产品可以是没有任何关系的对象，但是它们都具有一些共同的约束，如同一操作；
6. 系统下的按钮和文本框，按钮与文本框之间没有直接关系，但它们都是属于某一操作系统的，此时具有一个共同的约束条件：操作系统的类型；
7. 产品等级结构稳定，设计完成之后，不会向系统中增加新的产品等级结构或者删除已有的产品等级结构。

[guyueshui]

分享一个讲设计模式的网站：https://refactoringguru.cn/design-patterns/flyweight
还有菜鸟教程，我们永远的朋友：https://www.runoob.com/design-pattern/flyweight-pattern.html

[guyueshui]

所有设计模式的终极目标：高内聚，低耦合。

[guyueshui]

正交四原则：最小化重复、分离变化、缩小依赖范围、向稳定方向依赖

SOLID原则：

• 单一职责（SRP)：一个对象应该只包含单一职责，并且将完整封装到一个类中
• 开闭原则，向扩展开放/向修改封闭（OCP）：一个软件应该对扩展开放，修改关闭。
• 子类要能替换父类/里式替换原则(LSP)：派生的子类可替换基类，即任何基类可以出现的地方，子类一定可以出现。
• 接口隔离/最小化接口依赖(ISP)：一个接口应该拥有尽可能少的行为，它是精简单一的
• 依赖倒置/只依赖接口(DIP)：高层模块不应该依赖底层模块，都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。

[guyueshui]

简单设计，简简单单才是真，平平淡淡就是福。如果你觉得上面的原则很艰深，我们现在来看一下简单设计的四个原则：

1. 通过所有测试：软件系统正确完成外部需求，包括功能性需求和非功能性需求，并通过了客户验收的标准
2. 尽可能消除重复：让软件走向高内聚，低耦合，达到良好的正交性的过程。注意并不是所有的重复都可以消除，这里是指最小化重复
3. 尽可能清晰表达：漂亮的代码如同优美的散文，从不隐藏设计者的意图，恰如其分的抽象，直截了当的控制。代码被阅读的次数远远大于其修改的次数
4. 更少的代码元素：尽可能降低设计的复杂度，保持简单

[guyueshui]

GoF设计模式包括23个设计模式，3大类：

• 创建型：对象的创建和程序行为解耦；
• 行为型：不同对象间的交互；
• 结构型：不同的对象组成的关系。

[guyueshui]

有关重构的讨论

重构时机

• 添加功能时
• 修补错误时
• review代码时

什么时候不适合做重构？

• 代码太混乱，设计完全错误，与其重构，不如重写
• 明天就是ddl，永远不要做“最后一分钟的修改”
• 重构工作量过大，需要谨慎安排
• 没有任何更好的思路时，不要重构

重构的陷阱

• 七零八碎，无法复原
• 分支开发，难以集成
• 半途而废，迷途难返
• 孤注一掷，进退两难

重构需要小步做，谨慎大规模重构。小步前进，随时可用，随时可停，随时回退。大步容易跑偏，难以还原，工作量大，浪费之前的工作。

特别提醒：如果发现跑偏，及时回头，千万不要硬着头皮搞，往往越陷越深。

重构原则：

• 添加新功能时，不应该修改既有代码，只管添加新功能
• 重构时，不能添加功能，只管改进程序结构

一次只做一件事，切勿边重构，边改问题！

[guyueshui]

十六字箴言：旧的不变，新的创建，一步切换，旧的再见！

[guyueshui]

提炼函数（extract function）

• 提取功能，将部分代码提取到独立函数，方便复用和维护
• 提升可读性，提炼到一个独立的函数中，并以这段代码的用途为这个函数命名，方便理解

Tips: 函数命名是试金石，如果不能为该函数起一个好名字，说明提炼范围需要修改，提炼范围功能不完整。

[guyueshui]

责任链模式

一个请求，需要多方处理，一环一环处理，可随时结束处理（可能处理成功，也可能处理失败）。此时可以使用责任链模式，提供一个一个的处理单元（这些处理单元可以有基类，将公共代码置于此），每个处理单元接受完整的请求及相关数据，并提供统一的接口（例如execute）对其进行处理。处理之后，可以立刻中断，可以传递给下一个处理单元接着处理。每个处理单元可以动态或静态地设置好自己的下一个处理单元。

应注意：

• 链中可能只有单个链接。
• 部分请求可能无法到达链尾。
• 其他请求可能直到链尾都未被处理。

---

不过还有一种稍微不同的方式 （也是更经典一种）， 那就是处理者接收到请求后自行决定是否能够对其进行处理。 如果自己能够处理， 处理者就不再继续传递请求。 因此在这种情况下， 每个请求要么最多有一个处理者对其进行处理， 要么没有任何处理者对其进行处理。 在处理图形用户界面元素栈中的事件时， 这种方式非常常见。

[guyueshui]

This comment is added directly in github discussion