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

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


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

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

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

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

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

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

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

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

相关推荐
无限进步_1 小时前
C语言字符串连接实现详解:掌握自定义strcat函数
c语言·开发语言·c++·后端·算法·visual studio
oscar9991 小时前
CSP-J教程——第一阶段——第二课:变量与数据类型
c++·数据类型·csp-j
qwepoilkjasd1 小时前
RapidJSON 完整学习指南
c++
一朵筋斗云1 小时前
c++
c++
有趣的我2 小时前
关于stub和mock
c++
Yupureki2 小时前
从零开始的C++学习生活 18:C语言复习课(期末速通)
c语言·数据结构·c++·学习·visual studio
数据知道2 小时前
Go语言设计模式:原型模式详解
设计模式·golang·原型模式
永远有缘3 小时前
四种编程语言常用函数对比表
java·开发语言·c++·python
C++_girl3 小时前
c++、java/python语言有什么区别?为什么c++更快?
java·开发语言·c++
艾莉丝努力练剑3 小时前
【Linux权限 (二)】Linux权限机制深度解析:umask如何决定默认权限与粘滞位的妙用
大数据·linux·服务器·c++·ubuntu·centos·1024程序员节