软件设计之美
郑晔
推文科技技术VP,前火币网首席架构师
立即订阅
3458 人已学习
课程目录
已完结 36 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 软件设计,应对需求规模的“算法”
免费
课前必读 (3讲)
01 | 软件设计到底是什么?
02 | 分离关注点:软件设计至关重要的第一步
03 | 可测试性: 一个影响软件设计的重要因素
了解一个软件的设计 (4讲)
04 | 三步走:如何了解一个软件的设计?
05 | Spring DI容器:如何分析一个软件的模型?
06 | Ruby on Rails:如何分析一个软件的接口?
07 | Kafka:如何分析一个软件的实现?
设计一个软件—程序设计语言 (5讲)
08 | 语言的模型:如何打破单一语言局限,让设计更好地落地?
09 | 语言的接口:语法和程序库,软件设计的发力点
10 | 语言的实现:运行时,软件设计的地基
11 | DSL:你也可以设计一门自己的语言
加餐 | 再八卦几门语言!
设计一个软件—编程范式 (9讲)
12 | 编程范式:明明写的是Java,为什么被人说成了C代码?
13 | 结构化编程:为什么做设计时仅有结构化编程是不够的?
14 | 面向对象之封装:怎样的封装才算是高内聚?
15 | 面向对象之继承:继承是代码复用的合理方式吗?
16 | 面向对象之多态:为什么“稀疏平常”的多态,是软件设计的大杀器?
17 | 函数式编程:不用函数式编程语言,怎么写函数式的程序?
18 | 函数式编程之组合性:函数式编程为什么如此吸引人?
19 | 函数式编程之不变性:怎样保证我的代码不会被别人破坏?
加餐 | 函数式编程拾遗
设计一个软件—设计原则与模式 (7讲)
20 | 单一职责原则:你的模块到底为谁负责?
21 | 开放封闭原则:不改代码怎么写新功能?
22 | Liskov替换原则:用了继承,子类就设计对了吗?
23 | 接口隔离原则:接口里的方法,你都用得到吗?
24 | 依赖倒置原则:高层代码和底层代码,到底谁该依赖谁?
25 | 设计模式:每一种都是一个特定问题的解决方案
26 | 简单设计:难道一开始就要把设计做复杂吗?
设计一个软件—设计方法 (3讲)
27 | 领域驱动设计:如何从零开始设计一个软件?
28 | 战略设计:如何划分系统的模块?
29 | 战术设计:如何像写故事一样找出模型?
巩固篇 (3讲)
30 | 程序库的设计:Moco是如何解决集成问题的?
31 | 应用的设计:如何设计一个数据采集平台?
32 | 应用的改进:如何改进我们的软件设计?
结束语 (1讲)
结束语|那些没讲的事儿
软件设计之美
15
15
1.0x
00:00/00:00
登录|注册

21 | 开放封闭原则:不改代码怎么写新功能?

郑晔 2020-07-15
你好!我是郑晔。
上一讲,我们讲了一个最基础的设计原则:单一职责原则,从这个原则中,你知道了一个模块只应该包含来自同一个变化来源的内容。这一讲,我们来看下一个设计原则:开放封闭原则。
作为一名程序员,来了一个需求就要改一次代码,这种方式我们已经见怪不怪了,甚至已经变成了一种下意识的反应。修改也很容易,只要我们按照之前的惯例如法炮制就好了。
这是一种不费脑子的做法,却伴随着长期的伤害。每人每次都只改了一点点,但是,经过长期积累,再来一个新的需求,改动量就要很大了。而在这个过程中,每个人都很无辜,因为每个人都只是遵照惯例在修改。但结果是,所有人都受到了伤害,代码越来越难以维护。
既然“修改”会带来这么多问题,那我们可以不修改吗?开放封闭原则就提供了这样的一个新方向。

不修改代码

开放封闭原则是这样表述的:
软件实体(类、模块、函数)应该对扩展开放,对修改封闭。
这个说法是 Bertrand Meyer 在其著作《面向对象软件构造》(Object-Oriented Software Construction)中提出来的,它给软件设计提出了一个极高的要求:不修改代码。
或许你想问,不修改代码,那我怎么实现新的需求呢?答案就是靠扩展。用更通俗的话来解释,就是新需求应该用新代码实现。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件设计之美》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥19.9
立即订阅
登录 后留言

精选留言(8)

  • 业余爱好者
    第一个案例感觉就是把user类改成了充血模型,这样确实合理一些,因为价格生成策略因用户不同而不同,同时又加入userlevel类,这样就更职责单一了。


    第二个案例从方法命名上就可以看出职责不单一了,连原作者都不知道这个方法干了什么,只好叫“process”这么泛泛的名字。

    Unix那个,是“提供策略,而不是机制”吧,可能记错了,一直搞不清机制和策略是什么意思。

    作者回复: 去看看《Unix 编程艺术》,非常值得读的一本好书。

    2020-07-15
    1
    5
  • liliumss
    DDD的思路我觉得比较适合做,难就难到领域建模

    作者回复: DDD只能帮助你把骨架建起来,其中的细节,还是需要遵循着设计原则进行调整。

    2020-07-19
    4
  • Being
    可以简单说下我们公司GIS平台的框架,也是插件的扩展机制。比如对于不同文件的格式解析和保存,抽象出DataSource模型和Saver模型,作为一类数据源注册进插件模块来扩展,而框架则提供类似驱动的能力,由用户组合需要的数据源放入驱动,然后通过驱动,来获得按流程处理后的文件导出。

    作者回复: 很好的分享!

    2020-07-16
    3
  • 阳仔
    1、识别修改点,构建模型,将原来静态的逻辑转为动态的逻辑
    2、构建模型的难点在于分离关注点,其次就是
    找到共性

    作者回复: 非常好的总结!

    2020-07-15
    2
  • PM2
    java的SPI给开发者提供了不错的扩展机制,像spring boot 和dubbo就在此基础上做了改进,各自提供了扩展点,spring boot允许用户自定义starter,dubbo可以自定义协议等

    作者回复: 很好的分享

    2020-08-07
    1
  • 石马
    机制与策略的关系,在我的理解来看,机制就像是车的离合和油门,而策略则是不同的驾驶方式,配合就起来可以完成不同的飘移效果

    作者回复: 机制应该是引擎吧?

    2020-08-04
    1
    1
  • 桃子-夏勇杰
    软件系统是变与不变的交融艺术,变化带来发展,不变的是本质,是共性。没有不变的变化只是绚丽的海市蜃楼,透过变化抓住不变,才是抓住了核心与要义。

    作者回复: 写出了一种诗意。

    2020-07-28
    1
  • Harry

    第一个例子不太好理解,
    第二个就相对容易多了
    2020-07-23
    1
收起评论
8
返回
顶部