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

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


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

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

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

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

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

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

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

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

相关推荐
景彡先生3 小时前
C++并行计算:OpenMP与MPI全解析
开发语言·c++
归去_来兮5 小时前
深度学习模型在C++平台的部署
c++·深度学习·模型部署
pay4fun6 小时前
2048-控制台版本
c++·学习
hjjdebug7 小时前
ffplay6 播放器关键技术点分析 1/2
c++·ffmpeg·音视频
Azxcc08 小时前
C++异步编程入门
开发语言·c++
吐泡泡_8 小时前
C++(STL源码刨析/vector)
c++
你的冰西瓜8 小时前
C++排序算法全解析(加强版)
c++·算法·排序算法
特立独行的猫a9 小时前
11款常用C++在线编译与运行平台推荐与对比
java·开发语言·c++
笑鸿的学习笔记9 小时前
qt-C++笔记之setCentralWidget的使用
c++·笔记·qt
苏克贝塔10 小时前
Qt 图形视图框架3-事件处理与传播
c++·qt