本文章属于专栏- 概述 - 《设计模式（极简c++版）》-CSDN博客
计算系统，是物理世界的一部分。各行各业的历史经验告诉我们，没有一劳永逸，一成不变的模式，而软件系统的设计模式也一样。要正确地使用一个规则，我们就需要正确地理解这个规则出现的背景，和当时要解决的问题。
90年代，互联网还没有普及，用户量有限，机器资源有限，开发人员的培养成本高，所以通过设计模式，增加开发一致性，可扩展性和代码复用，降低开发、维护成本，是企业推崇的。而设计模式的目标是，将开发过程标准化，降低项目需要投入的开发、维护人员。基于这个背景，我们不难理解为什么一部分设计模式，以牺牲性能的代价，换取程序的扩展性。所以设计模式不是适合所有场景，一味地刻舟求剑，只会被市场抛弃。
以现代的ToC的分布式系统为例，特别是机器成本远超人员成本的场景。一些常见的错误用法，如：
- 使用中介模式，为了所谓的未来扩展，增加多个中介。没有组织隔离的效果，却增加数据传输的成本
- 每次增加一个新功能，都添加一个装饰器，不仅导致代码越来越难维护，性能也越来越差，唯一的收益或许是代码"好像"很专业
- 服务0->1阶段，将可以放在一起运行的代码逻辑，拆分到多个处理器中，导致CPU的局部性显著下降，不仅降低的程序运行性能，还增加了代码阅读成本
- 用户流式处理时，为了还原，使用备忘录模式，将多个时刻的用户快照保存，导致超高的网络、存储成本
以上例子都是我见过的实际应用中，错误使用的例子。这些大部分都和一个固化的错误观念有关系："有设计模式"永远比"没有设计模式好"，"面向对象"永远比"面向过程"好。
各个业务场景不同，甚至相同业务在不同公司的开发风格也不一致，那实际应用中如何抉择呢，我的思考方法是：
- 应用高频调用的CPU密集型逻辑，不使用影响性能的设计模式。
- 应用低频调用的逻辑
- 只在接口层和输出层，使用和组织隔离相关的设计模式
- 应用低频调用的，可能频繁改动的业务链路的相关逻辑
- 沉淀一套，个人使用得心应手的模式，最好将这套逻辑，剥离业务抽象出自己的框架。方便复用
最后，如何在开发中，特别是项目0->1的时候，发现不用设计模式，想不到有什么明显的问题，就建议先不用，错误地使用远比不适用伤害更大。等业务发展到一定阶段，再来做语义的抽象，然后选择对应的设计模式。毕竟"过早的优化是万恶之源"。