许式伟的架构课
许式伟
七牛云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 | 架构老化与重构
许式伟的架构课
登录|注册

63 | 接口设计的准则

许式伟 2019-12-10
你好,我是七牛云许式伟。
上一讲 “62 | 重新认识开闭原则 (OCP)” 我们介绍了开闭原则。这一讲的内容非常非常重要,可以说是整个架构课的灵魂。总结来说,开闭原则包含以下两层含义:
第一,模块的业务要稳定。模块的业务遵循 “只读” 设计,如果需要变化不如把它归档,放弃掉。这种模块业务只读的思想,是架构治理的基础哲学。我平常和小伙伴们探讨模块边界的时候,经常会说这样一句话:
每一个模块都应该是可完成的。
这实际上是开闭原则的业务范畴 “只读” 的架构治理思想的另一种表述方式。
第二,模块业务的变化点,简单一点的,通过回调函数或者接口开放出去,交给其他的业务模块。复杂一点的,通过引入插件机制把系统分解为 “最小化的核心系统 + 多个彼此正交的周边系统”。事实上回调函数或者接口本质上就是一种事件监听机制,所以它是插件机制的特例。
今天,我们想聊聊怎么做接口设计。
不过在探讨这个问题前,我想和大家探讨的第一个问题是:什么是接口?
你可能会觉得这个问题挺愚蠢的。毕竟这几乎是我们嘴巴里天天会提及的术语,会不知道?但让我们用科学家的严谨作风来看待这个问题。接口在不同的语义环境下,主要有两个不同含义。
一种是模块的使用界面,也就是规格,比如公开的类或函数的原型。我们前面在这个架构课中一直强调,模块的接口应该自然体现业务需求。这里的接口,指的就是模块的使用界面。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • Aaron Cheung
    所以orm是否还有必要呢 ruby python go 都有挺多ORM

    作者回复: 少用

    2019-12-10
    2
  • 老师,是我们的平台想记录用户的浏览轨迹了,我又不想将记录功能分布到各个模块中,有什么好的办法吗?

    作者回复: 在入口去记录。比如服务端的入口进行记录,或者前端统一进行记录。

    2019-12-11
    1
    1
  • 老师,浏览日志和操作日志怎么设计合理一些

    作者回复: 就是文中说的 logger?一般在应用最外层选定 logger,可能写到一个滚动的日志文件,也可能发到一个分布式的日志收集平台。

    2019-12-11
    1
    1
  • Jxin
    mock外部依赖,以实现本服务的独立测试与交付。
    2019-12-10
    1
  • 靠人品去赢
    接口其实就是一个解耦的,你别管我怎么实现的你就按着接口来传参就好了。
    所以我觉得,所以内部其实可以少用接口,继承也要更少用,多用组合的方式。
    对外部提供接口,尽量的设计好,不要一大堆参数,实在不行你传个对象也行,保证最简洁
    2019-12-10
    1
  • Charles
    架构师应该站在全局高位考虑项目,所以开发效率和架构设计以及扩展之间,有时候追求的是一种平衡,没绝对是吗?
    2019-12-10
  • leslie
    “大部分情况下应该选择直接依赖组件,而不必去抽象”说起这个其实就像我们去提及工具或者说功能和可扩展性的取舍。用中间件存储的rabbitMQ和kafka在高并发方面来举例:
          rabbitMQ:rabbit在高并发场景下确实比kafka强-阿里多次双11中历经考验,不过源代码代码的空间改造性相对kafka难许多,符合老师所说的直接用,不过一旦使用其替代方案就困难;
          kafka:性能虽不如rabbitmq耐抗,不过其源代码思路简单改造性容易,符合老师课程中的“最少知识原则(Least Knowledge Principle,LKP)”。
           两种方式的取舍其实很多时候还是看场景:相辅相成可能有时更可以充分发挥特性。
    2019-12-10
  • 有铭
    我记得ORM这个东西之所以诞生的一个重要原因就是大约15年,切换关系数据库是一种刚需,当然现在已经是伪命题了
    2019-12-10
  • 丁丁历险记
    目读完后想听一遍,发现没有声音,睡觉。
    2019-12-10
收起评论
9
返回
顶部