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

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


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

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

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

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

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

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

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

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

  • 18
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值