许式伟的架构课
许式伟
七牛云CEO
立即订阅
20237 人已学习
课程目录
已更新 75 讲 / 共 87 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (12讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
64 | 不断完善的架构范式
65 | 架构范式:文本处理
66 | 架构老化与重构
许式伟的架构课
登录|注册

62 | 重新认识开闭原则 (OCP)

许式伟 2019-12-06
你好,我是七牛云许式伟。
架构的本质是业务的正交分解。
在上一讲 “61 | 全局性功能的架构设计” 中我们提到,架构分解中有两大难题:其一,需求的交织。不同需求混杂在一起,也就是存在所谓的全局性功能。其二,需求的易变。不同客户,不同场景下需求看起来很不一样,场景呈发散趋势。
我们可能经常会听到各种架构思维的原则或模式。但,为什么我们开始谈到架构思维了,也不是从那些耳熟能详的原则或模式谈起?
因为,万变不离其宗。
就架构的本质而言,我们核心要掌握的架构设计的工具其实就只有两个:
组合。用小业务组装出大业务,组装出越来越复杂的系统。
如何应对变化(开闭原则)。

开闭原则(OCP)

今天我们就聊聊怎么应对需求的变化。
谈应对变化,就不能不提著名的 “开闭原则(Open Closed Principle,OCP)”。一般认为,最早提出开闭原则这一术语的是勃兰特·梅耶(Bertrand Meyer)。他在 1988 年在 《面向对象软件构造》 中首次提出了开闭原则。
什么是开闭原则(OCP)?
软件实体(模块,类,函数等)应该对于功能扩展是开放的,但对于修改是封闭的。
一个软件产品只要在其生命周期内,都会不断发生变化。变化是一个事实,所以我们需要让软件去适应变化。我们应该在设计时尽量适应这些变化,以提高项目的稳定性和灵活性,真正实现 “拥抱变化”。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • 梦醒十分
    入木三分,好文章!
    2019-12-06
    8
  • leslie
    老师的课程中提及的两方面是我觉得自己理解的最不好的:一方面"基础架构 + 业务架构,才是你设计的软件的全部",另一方面"一方面从中学习怎么做需求分析,另一方面也从中体悟做架构的思维哲学"。
          如同老师所说的"架构课 的革命性,我自己从没怀疑过。它的内容是精心设计的,为此我准备了十几年",学习的过程中我其实同样在整体梳理自己作为DBA&&OPS十余年松散的知识体系。老师开课的这半年多不断的适度扩展梳理去破未知,完成了20余门功课的学习;除了画图部分的知识都是在不断的循环梳理。虽不断学习和梳理,但是依然觉得老师今天课程中提及的两方面其实是最难。如同前几天DevOps课程的石老师课程提出的Plan-Do-Check-Act时,我说这个顺序其实可以改变且石老师的回复中对此非常认可一样。这个认知其实是原来许老师课程的循环反复,梳理中悟出的东西。
          结合老师上堂课所提及"任何功能都是可以正交分解的,即使我目前还没有找到方法,那也是因为我还没有透彻理解需求"-可以理解为业务方面的。《全局性功能的架构设计》和《重新认识开闭原则》两章内容在强调今天课程结束老师的"基础架构 + 业务架构,才是你设计的软件的全部"。
          以上是个人结合这两节课的知识对于今天课程结束部分老师的理解:谢谢老师的分享和教诲。期待老师的下次分享。

    作者回复: 作为架构师,要深刻认识到一点,光理解架构哲学不足以做好架构,它是让我们判断对与错的法则。要真正做好架构,需要做好业务需求分析,做好正交分解,做好模块边界定义。这些不断梳理清楚的“只读”的业务模块,是架构师真正的武器库。

    2019-12-06
    7
  • K战神
    许大,希望出书。买来收藏。

    时不时枕边翻阅体会大佬的思想。

    多年以后,庆幸自己这段时间跟着许大的专栏,有了新的想法和思想。

    作者回复: 后面应该会出书

    2019-12-06
    4
  • Jxin
    笔记:

    将开闭原则上移到业务系统。业务对外只读,意味着不可变,但不变的业务生命周期是很短暂的,所以要可扩。要扩展还要不变,就倒逼着要做兼容,而兼容可能会导致现有的功能职责不单一,这又倒逼着要对现有的功能做再抽象,以适应更广的“单一职责”。

    所以不改是不可能的,只是改的结果应当是让项目往更稳定去发展。然而这里面其实好难,无论是新的抽象的定义还是职责范围的扩张,这都需要有强大的分析能力和精湛的设计思维、重构手法、调优能力以及站在核心目标上的权衡来支撑。然而难亦是乐趣所在。

    作者回复: 👍

    2019-12-06
    2
  • Geek_88604f
    在业务正交分解的过程中必然会遇到以前分解好的模块需要调整的情况,比如说随着新模块的加入发现和老模块的部分实现有重复的情况。这种情况下是保持新老模块的重复部分呢还是抽取出共同的部分作为更基础的支撑模块呢?如果要抽取共同的模块必然会涉及老模块的修改,这种情况是否有违反了开闭原则呢?更进一步开闭原则和重构的关系应该如何处理?

    作者回复: 我认为不是不修改,是不改变业务范畴,不轻易改变改变模块的使用界面

    2019-12-10
    1
  • Yayu
    如何理解“只读”模块?

    作者回复: 不是代码只读,是业务范畴只读,接口尽可能只读(增加方法以兼容的方式进行)。

    2019-12-06
    2
    1
  • 沫沫(美丽人生)
    许老师好,很感谢您上次关于PaSS问题的回复,读您的文章让我受益匪浅。还想请教一个问题,像Salesforce是基于元数据来构建系统的,元数据在信息架构里属于什么范畴呢,可以展开来讲一讲吗?盼复。

    作者回复: Model 层

    2019-12-06
    2
    1
  • 轶名
    功力深厚啊
    2019-12-13
  • K战神
    许大,我们真的要考虑,将老的需求放入版本库。对于新的重新实现一个新的。

    会不会最后系统会有很多名字类似业务有所区别的接口?

    作者回复: 这方面代码管理有很多成熟的实践了,版本管理上

    2019-12-11
  • ljf10000
    感觉开闭原则跟自底向上设计很相似,都是先构建稳定的底层模块/机制,再一层层组合出来。
    2019-12-10
  • tt
    本课感受最深的一句话:

    “第二,模块的业务变化点,简单一点的,通过回调函数或者接口开放出去,交给其他的业务模块。复杂一点的,通过引入插件机制把系统分解为 “最小化的核心系统 + 多个彼此正交的周边系统”。事实上回调函数或者接口本质上就是一种事件监听机制,所以它是插件机制的特例。”

    由业务到数据,由核心到周边,再把这个过程映射到开闭选择,再把开放性具体到插件与接口,下节课讲接口。老师这三节课真是步步深入啊。:

    偷懒得说,要是画图代码在通用一些就好了

    作者回复: 业务系统都是相通的

    2019-12-08
  • 阿卡牛
    没有基本功,是很难读懂许老师的深层含义打,只能用苦功,下巧劲
    2019-12-06
  • 醍醐灌顶,再多的语言也无法表达,最好的架构课
    2019-12-06
  • nanquanmama
    值回票价
    2019-12-06
  • 靠人品去赢
    这么一想,微服务其实也是单一职责原则的实现。像普通业务的话,不清晰以后的方向,可能现在是工具类,后来又搞商城类,侧重点变化可能无法一下子就确定那些是稳定点,做着做着又是一大坨,哪里不行搞哪里,这种怎么解?

    作者回复: 需求洞察本来就是架构的难点

    2019-12-06
  • Aaron Cheung
    基础架构 + 业务架构,才是你设计的软件的全部。作为架构师,千万不要一叶障目,不见泰山,忘记基础架构选择的重要性。 基础架构是地基
    2019-12-06
  • 丁丁历险记
    笔记 ocp 是根基,lsv原则用于保障ocp。 srp 让实现lsv 更简单,就一个引起变更职责代码不容易腐化。 这样出来的代码正交性更好,更容易组合。
    2019-12-06
  • :)
    通过老师的文章的一些思考。
    1. 事情变得复杂往往有两个方面的原因。1.联系耦合过多 2.变化过多
    2. 架构的目的就是让事情变得,简单,清晰。
    3. 应对耦合过多,可以使用单一原则。
    4. 应对变化过多,可以用开闭原则,而其中的"只读",让自己有种醍醐灌顶的感觉。
    2019-12-06
收起评论
18
返回
顶部