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

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

许式伟 2019-07-26
你好,我是七牛云许式伟。
前面的两节课结束后,我们的画图程序已经基本实用。它有如下功能:
可以选择全局的图形样式(lineWidth、lineColor、fillColor);
可以以全局的图形样式来创建各类图形(Path、FreePath、Line、Rect、Ellipse、Circle);
可以选择已经创建的图形,并修改其图形样式;
可以删除选择的图形;
可以移动选择的图形。
前面有一些同学的反馈,我这里想回答一下。
有一个反馈是对 JavaScript 的使用,我为什么会用 class 关键字。
这是因为我不太希望这是一篇某个语言的教程,我选择的是如何用最接近大家思维的表达方式来表达程序逻辑,你就算没有系统学过 JavaScript,也应该能够理解这段程序想要做什么。
另外有一个反馈,是希望我不要一上来就从 MVC 这种模式讲起,而是如果没有 MVC,我们用最基础的裸写代码,会写出一个什么样的程序来,里面有哪些弊端,从而引入 MVC 来让程序架构变得更加清晰,功能之间解耦。
这个意见我觉得是比较中肯的,后面我们会补充一讲来裸写 MVP 版本的画图程序。
今天我们开始进入“实战:怎么设计一个‘画图’程序”的第三讲,怎么和服务端连接。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 风清扬
    老师,localid可以理解为服务端id,display id是客户端id吗?displayid记录客服端用户操作轨迹,每次同步后,如果用户修改,则display id变更为下一个。而localid始终不变,与服务端同步数据时,用的也是它。

    作者回复: localID 是这篇文档在本地的唯一id,本地是指该浏览器。displayID 有两个可能:一个是创建该文档之初,会有一个临时id,其实就是 t<localID>。另一个是这篇文档被同步到服务端,服务端返回它为这篇文档分配的id。

    2019-07-26
    3
  • 黄伟洪
    许先生的课,真是收益匪浅!
    2019-07-28
    2
  • 有铭
    localID倒是能理解,其实就是这个文件本身,一旦建立,就不动了,但是displayID会变化?每改一次就会变吗?那这东西是不是有点类似git等版本管理工具的提交版本号?是这个意思吗?也就是说其实你支持回退能力

    作者回复: 不是每改一次会变,只有两个状态,一个是没有连上服务器时的id,一个是连上服务器后

    2019-07-26
    1
  • Bing573
    我们最近在做一款可视化编辑器时,整个文档是采用的JSON格式存储的。由于没采用分层,所以每次有任何改动都需要保存整个文档。但程序在结构和操作上感觉比分层这种方式简单,对可视元素的操作反映为对JSON的操作也很直观,而且每次保存整个文档似乎也没什么不妥,所以不太理解为何需要采用分层的形式?

    作者回复: 你之所以觉得没必要分层,核心原因是dom比较简单,就一个json,所以业务逻辑也不会复杂到哪里去,直接以json操作接口作为dom的操作接口了。在简单应用中这种情况下不分层问题不会特别大。

    2019-10-14
  • 笛神
    希望老师可以将这几讲的内容用图形表达出来,分为哪几层,每一层职责如何,关系如何,这样理解起来比较形象一点

    作者回复: 如果觉得比较难理解,可以先看 32 讲里面给出的裸写代码,它不分mvc,所有代码都在一起。

    2019-09-10
  • 恒修
    model层数据变化怎么通知view层?

    作者回复: 事件

    2019-08-02
  • 恒修
    数据驱动view层变化
    2019-08-02
  • Aaron Cheung
    打卡28 js
    2019-07-27
  • 许童童
    老师,这一节读懂了。
    2019-07-26
  • 路伴友行
    看了架构整洁之道这本书,不知道大佬会不会讲整洁架构

    作者回复: 会讲,第四章专门谈架构。我们前面几章也会穿插架构的话题

    2019-07-26
收起评论
10
返回
顶部