许式伟的架构课
许式伟
七牛云CEO
立即订阅
19936 人已学习
课程目录
已更新 71 讲 / 共 77 讲
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 | 服务治理篇:回顾与总结
架构思维篇 (8讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
许式伟的架构课
登录|注册

27 | 实战(二):怎么设计一个“画图”程序?

许式伟 2019-07-23
你好,我是七牛云许式伟。
上一讲开始,我们进入了实战模式。从目前看到的反馈看,我的预期目标并没有达到。
我复盘了一下,虽然这个程序看起来比较简单,但是实际上仍然有很多需要交代而没有交代清楚的东西。
我个人对这个例子的期望是比较高的。因为我认为 “画图” 程序非常适合作为架构实战的第一课。“画图” 程序需求的可伸缩性非常大,完完全全是一个迷你小 Office 程序,很适合由浅及深去谈架构的演进。
所以我今天微调了一下计划,把服务端对接往后延后一讲,增加一篇 “实战(中)” 篇。这个“中”篇一方面把前面 “实战(上)” 篇没有交代清楚的补一下,另一方面对 “画图” 程序做一次需求的迭代。

MVP 版画图程序

先回到 “实战(上)” 篇。这个版本对画图程序来说,基本上是一个 MVP 版本:只能增加新图形,没法删除,也没法修改。
怎么做?我们先看 Model 层,它的代码就是一个 dom.js 文件。从数据结构来说,它是一棵以 QPaintDoc 为根的 DOM 树。这个 DOM 树只有三级:Document -> Shape -> LineStyle。具体细节可以参阅下表:
这个表列出的是 Model 和 View、Controllers 的耦合关系:Model 都为它们提供了什么?可以看出,View 层当前对 Model 层除了绘制(onpaint),没有其他任何需求。而各个 Controller,对 Model 的需求看起来似乎方法数量不少,但是实质上目的也只有一个,那就是创建图形(addShape)。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(20)

  • 有铭
    老师,我知道你这章讲了很厉害的东西,但是我也只能和上面某人说的一样,说一声:“不明觉厉”。原因不在别的,抽象现实需要对现实有很长时间的切身体会,必须要经历痛苦,有痛彻灵魂,深刻的总结,才能体会到解决方案的甜美。这里的大部分人,包括我在内,没有在实践里经历“从头构建一个画图”程序。所以对于这章的知识,看得懂,但是难有感悟,换个场景,就使不出来

    作者回复: 理解,我想一下怎么才能说得更明白。这里面每一个角色的分解是有非常明确的套路可循,遵循文章中说的几个要点即可。

    2019-07-23
    10
  • Being
    实战一二的例子套用前面的知识点,对MVC的理解慢慢清晰了。更重要的是在实战的学习中也结合现在自己手头的项目进行思考。现在在做地图方面结合图元的绘制,目前的平台是Qt。我负责的是图元模块,即要对图元抽象并且使用Qt的绘制方法,当然,对于Qt的部分是严格控制在绘制部分的,也是考虑了跨平台的因素。图元部分其实是抽象了接口的,对于上层的调用完全不用关心底层绘制是用的什么平台。整个项目也是明确了几个模块来管理和组织事件、绘制、地图数据、资源引擎、算法等。仔细考虑下来,也是绕不开MVC给的模式的。有一个很明显的感受是,关于Controller层,是可以扩展成插件的,也就是说,Controller基于业务上的各种需求,也需要更大的灵活性。思考是,完全可以把事件管理起来,抽象出事件核心驱动,然后分配给各个Controller各取所需,至于是插件还是观察者,其实就是具体实现机制的区别了。

    作者回复: 我们这个例子其实controller都是插件,只是在init application的时候创建一下就完了,是不是实现成标准plugin机制不是关键点

    2019-07-27
    2
  • 许童童
    每一个字都看得懂,但连到一起就看不懂了。

    作者回复: 明白。这些反馈对我很有收益。

    2019-07-23
    2
  • 3k
    MVC相对简单,可以讲讲微服务模型之类的架构么?

    作者回复: 这个在下一章,服务端架构

    2019-07-26
    1
  • Taozi
    多看几遍代码,先看v26分支,已经明朗很多了。谢谢。
    2019-07-24
    1
  • Charles
    许老师,我反复读了好久还是有点懵懂,可能要先去读下完整的源码再回来读可能好一些?

    作者回复: 最好能够先大致看一下代码

    2019-07-24
    1
  • 我的腿腿
    最近在看GoF的设计模式,里面也是用图形界面做例子引入某某模式,和作者的不谋而合,不过还是太抽象了!感觉在爬一座充满荆棘的山

    作者回复: 本例中什么地方没看懂?

    2019-07-23
    1
  • 糊李糊涂
    许大 这部分还是讲的有点 凌乱,我这写了4年web 愣是捋了半天,可能这种例子适合视频讲吧

    作者回复: 这块可能是因为我自己的背景的原因,有些知识想当然认为比较容易理解。后面还会就这个案例进行补充讲解。

    2019-09-03
  • zKerry
    接口之间的调用关系,最好用流程图啊,看图表有点懵。

    作者回复: 这里侧重点是模块边界,不是流程

    2019-08-26
  • 闫飞
    文中的表格是用VSCode自动生成的吗还是贴的图片?能否分享一下。

    描述静态结构确实UML会更直观一点

    作者回复: 是vscode

    2019-08-16
  • Geek_e55641
    流程图能够更清晰表示需求,组件图能够表示模块划分,类图显示设计依赖
    希望能用通用表示法,纯文字不太好理解
    2019-08-08
  • Geek_8476da
    感觉好难啊
    2019-08-06
  • Aaron Cheung
    补打卡 27
    2019-07-28
  • Demon.Lee
    我也没怎么看懂,估计是不会前端,看的时候我一直在告诉自己: 老师是要告诉我们,解耦,解耦,解耦!

    作者回复: 嗯,后面可以看一个不解耦的版本

    2019-07-27
  • 刘宗尧
    能类比一下移动的操作系统吗?android或者ios

    作者回复: 是说它们有什么差异?站在我们架构分析的纬度,两者大同小异

    2019-07-25
  • 梦醒十分
    好文章需要多看几遍。
    2019-07-24
  • Charles
    另外有个建议,文中的类、方法、事件这些用uml图或自定义流程图之类的表达会不会更直观一些?

    作者回复: 主要我们的侧重点是子系统(或模块)之间的耦合,所以并没有把关注点放在流程上

    2019-07-24
  • 有深度,模模糊糊懂,具体细节不太明白,没做过cs端的估计也看不懂

    作者回复: 其实这个程序虽然是b/s结构的,但是实质上是单机版本的,只需要看js代码即可

    2019-07-23
  • 筱恕
    感觉这一章有几本书的知识量
    2019-07-23
  • Jian
    代码面向扩展,面向对象,高内聚低耦合。设计者需要很强的抽象思维能力,才能设计出艺术品般的代码。开发者需要更多有效锤炼才能掌握这样的能力。
    2019-07-23
收起评论
20
返回
顶部