《在合适的地方使用设计模式》

本文章属于专栏- 概述 - 《设计模式(极简c++版)》-CSDN博客


计算系统,是物理世界的一部分。各行各业的历史经验告诉我们,没有一劳永逸,一成不变的模式,而软件系统的设计模式也一样。要正确地使用一个规则,我们就需要正确地理解这个规则出现的背景,和当时要解决的问题。

90年代,互联网还没有普及,用户量有限,机器资源有限,开发人员的培养成本高,所以通过设计模式,增加开发一致性,可扩展性和代码复用,降低开发、维护成本,是企业推崇的。而设计模式的目标是,将开发过程标准化,降低项目需要投入的开发、维护人员。基于这个背景,我们不难理解为什么一部分设计模式,以牺牲性能的代价,换取程序的扩展性。所以设计模式不是适合所有场景,一味地刻舟求剑,只会被市场抛弃。

以现代的ToC的分布式系统为例,特别是机器成本远超人员成本的场景。一些常见的错误用法,如:

  • 使用中介模式,为了所谓的未来扩展,增加多个中介。没有组织隔离的效果,却增加数据传输的成本
  • 每次增加一个新功能,都添加一个装饰器,不仅导致代码越来越难维护,性能也越来越差,唯一的收益或许是代码"好像"很专业
  • 服务0->1阶段,将可以放在一起运行的代码逻辑,拆分到多个处理器中,导致CPU的局部性显著下降,不仅降低的程序运行性能,还增加了代码阅读成本
  • 用户流式处理时,为了还原,使用备忘录模式,将多个时刻的用户快照保存,导致超高的网络、存储成本

以上例子都是我见过的实际应用中,错误使用的例子。这些大部分都和一个固化的错误观念有关系:"有设计模式"永远比"没有设计模式好","面向对象"永远比"面向过程"好。

各个业务场景不同,甚至相同业务在不同公司的开发风格也不一致,那实际应用中如何抉择呢,我的思考方法是:

  • 应用高频调用的CPU密集型逻辑,不使用影响性能的设计模式。
  • 应用低频调用的逻辑
    • 只在接口层和输出层,使用和组织隔离相关的设计模式
  • 应用低频调用的,可能频繁改动的业务链路的相关逻辑
    • 沉淀一套,个人使用得心应手的模式,最好将这套逻辑,剥离业务抽象出自己的框架。方便复用

最后,如何在开发中,特别是项目0->1的时候,发现不用设计模式,想不到有什么明显的问题,就建议先不用,错误地使用远比不适用伤害更大。等业务发展到一定阶段,再来做语义的抽象,然后选择对应的设计模式。毕竟"过早的优化是万恶之源"。

相关推荐
另寻沧海1 天前
测试中的 AAA 模式与 Given–When–Then 模式详解
c++·单元测试·测试覆盖率
Q741_1471 天前
C++ 模拟题 力扣495. 提莫攻击 题解 每日一题
c++·算法·leetcode·模拟
阿维的博客日记1 天前
设计模式-代理模式
设计模式·代理模式
笨手笨脚の1 天前
设计模式-迭代器模式
java·设计模式·迭代器模式·行为型设计模式
青岛少儿编程-王老师1 天前
CCF编程能力等级认证GESP—C++7级—20250927
数据结构·c++·算法
Miki Makimura1 天前
Reactor 模式实现:从 epoll 到高并发调试
运维·服务器·c++·学习
·心猿意码·1 天前
C++Lambda 表达式与函数对象
开发语言·c++
o0向阳而生0o1 天前
109、23种设计模式之迭代器模式(18/23)
设计模式·迭代器模式
棉猴1 天前
GESP C++等级认证三级15-原码反码补码2-2
开发语言·c++·gesp·c++三级·等级认证·原码反码补码
老王熬夜敲代码1 天前
Etcd使用
c++·微服务·etcd