许式伟的架构课
许式伟
七牛云 CEO
84946 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 89 讲
许式伟的架构课
15
15
1.0x
00:00/00:00
登录|注册

63 | 接口设计的准则

模块的环境依赖
模块的使用界面
直接依赖组件 vs. 抽象化依赖
对参数的泛化与抽象
让人一眼就明白模块在做什么样的业务
通过引入插件机制分解系统为 "最小化的核心系统+多个彼此正交的周边系统"
通过回调函数或接口开放出去
模块的业务遵循 "只读" 设计
接口设计
实现依赖
使用界面依赖
最小依赖原则
例子:mockhttp.v1 vs. mockhttp.v2
KISS 原则
模块对依赖环境的抽象
模块的使用界面
模块业务的变化点
模块的业务要稳定
结语
模块的环境依赖
模块的使用界面
什么是接口?
开闭原则
接口设计的准则

该思维导图由 AI 生成,仅供参考

你好,我是七牛云许式伟。
上一讲 “62 | 重新认识开闭原则 (OCP)” 我们介绍了开闭原则。这一讲的内容非常非常重要,可以说是整个架构课的灵魂。总结来说,开闭原则包含以下两层含义:
第一,模块的业务要稳定。模块的业务遵循 “只读” 设计,如果需要变化不如把它归档,放弃掉。这种模块业务只读的思想,是架构治理的基础哲学。我平常和小伙伴们探讨模块边界的时候,经常会说这样一句话:
每一个模块都应该是可完成的。
这实际上是开闭原则的业务范畴 “只读” 的架构治理思想的另一种表述方式。
第二,模块业务的变化点,简单一点的,通过回调函数或者接口开放出去,交给其他的业务模块。复杂一点的,通过引入插件机制把系统分解为 “最小化的核心系统 + 多个彼此正交的周边系统”。事实上回调函数或者接口本质上就是一种事件监听机制,所以它是插件机制的特例。
今天,我们想聊聊怎么做接口设计。
不过在探讨这个问题前,我想和大家探讨的第一个问题是:什么是接口?
你可能会觉得这个问题挺愚蠢的。毕竟这几乎是我们嘴巴里天天会提及的术语,会不知道?但让我们用科学家的严谨作风来看待这个问题。接口在不同的语义环境下,主要有两个不同含义。
一种是模块的使用界面,也就是规格,比如公开的类或函数的原型。我们前面在这个架构课中一直强调,模块的接口应该自然体现业务需求。这里的接口,指的就是模块的使用界面。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

接口设计是架构设计中的重要内容,包括模块的业务稳定性和变化点的处理。在模块的使用界面方面,KISS原则(Keep it Simple, Stupid)是关键,要让接口简单自然,符合惯例。文章以七牛开源的mockhttp项目为例,说明了接口设计中的问题和改进。在模块的使用界面方面,接口应符合语言和社区的惯例,尽可能沿用相同的接口语义。文章强调了接口设计的重要性,以及如何根据KISS原则和语言惯例来设计接口,以提高模块的易用性和稳定性。文章还讨论了模块的环境依赖,包括使用界面依赖和实现依赖,强调了“最小依赖原则”和“最少知识原则”的重要性。在使用界面依赖方面,文章提到了参数的泛化与抽象,以适应更广泛的场景。而在实现依赖方面,建议大部分情况下选择直接依赖组件,而不必去抽象它。总的来说,接口设计是一个老生常谈的话题,对于模块的使用界面和环境依赖都有着重要意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(12)

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

    作者回复: 少用

    2019-12-10
    10
  • 超级伪装者杰瑞
    那作为基础存储的数据库是否应该抽象出来呢?

    作者回复: 数据库本身就有标准接口,重新包一次的意义不大

    2021-03-09
    2
  • 老师,浏览日志和操作日志怎么设计合理一些

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

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

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

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