如何落地业务建模
徐昊
ThoughtWorks中国区CTO
新⼈⾸单¥59.9
2261 人已学习
课程目录
已更新 17 讲 / 共 29 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词|为什么你需要学习业务建模?
免费
旧约:“前云时代”的领域驱动设计 (11讲)
01|领域驱动设计到底在讲什么?
02|统一语言是必要的吗?
03|我们要怎么理解领域驱动设计?
04|跨越现实的障碍(上):要性能还是要模型?
05|跨越现实的障碍(中):富含知识还是代码坏味道?
06 | 跨越现实的障碍(下):架构分层就对了吗?
07|统一语言可以是领域模型本身吗?
08 | 什么办法可以在讨论中自然形成统一语言?
09|怎么才能更有效地获得事件流?
10 | 将模型实现为RESTful API(上)
11|将模型实现为RESTful API(下)
深度答疑专题 (4讲)
说点题外话01|好耦和与坏耦和
说点题外话02|模式并不是解决方案
说点题外话03|银弹可以杀死狼人,但你怎么知道狼人不是你呢?
说点题外话04|面向对象的原则适用于RESTful API吗?
新约:云时代的业务建模 (1讲)
12|云时代的挑战(上):弹性边界还是业务边界?
如何落地业务建模
15
15
1.0x
00:00/00:00
登录|注册

说点题外话04|面向对象的原则适用于RESTful API吗?

你好,我是徐昊。今天我们再来专门说点题外话。
前面几期题外话都比较偏向于提供一种不同的角度,主要是因为你们也并没有针对课程的内容,提出什么特别的问题需要我来具体回答。那么作为我们在进入新约前的最后一篇题外话,我想聊一聊关于 RESTful API 的问题。
我记得有位同学在留言区问了这样一个问题:过长的 URI 是否破坏了迪米特法则(Law of Demeter)。这里我们就要搞清楚,什么是迪米特法则呢?
迪米特法则又叫最小可知法则,指的是在面向对象设计中,实体应尽可能少地与其他实体发生交互。为了说明什么是“少的交互”,我们还特别归纳了一组可以认为不违反迪米特法则,并且可以直接调用的对象:
当前对象自己(this,self);
以参数形式传入的对象,比如函数的形参(parameter);
当前对象内实例变量引用的对象(instance variable);
如果实例变量是集合,那么集合中的对象也可以访问(collection,aggregration);
由当前对象创建的对象(variable declaration in function)。
那么这些场景适用于 RESTful API 调用的场景吗?显然并不太适用。因为在 RESTful API 的场景中,实体只有客户端和 API 提供者,而 API 提供者的内在结构都被 API 层屏蔽了。所以无论怎么调用,都不会出现对于 API 提供者内部结构的依赖。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
该试读文章来自付费专栏《如何落地业务建模》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥59.9
立即订阅
登录 后留言

精选留言(1)

  • 邹溪源
    接口无处不在,而良好的设计则更显得非常重要。基于restful的架构风格设计接口,相比传统的http风格设计的接口,更易于引入面向对象的程序设计。这种设计也成为实践单一职责原则的练兵场。
    而有了接口,也使得依赖倒置成为一种基本操作。

    作者回复: 面向对象不面向对象单说 比较容易得到稳定的api

    2021-07-27
收起评论
1
返回
顶部