得墨忒耳定律 看起来很香,但是实践起来太繁琐了,还是我的理解有问题

2020-09-06 20:28:56 +08:00
 petelin

https://zh.wikipedia.org/wiki/%E5%BE%97%E5%A2%A8%E5%BF%92%E8%80%B3%E5%AE%9A%E5%BE%8B

可以简单地以下面任一种方式总结:

每个单元对于其他的单元只能拥有有限的知识:只是与当前单元紧密联系的单元; 每个单元只能和它的朋友交谈:不能和陌生单元交谈; 只和自己直接的朋友交谈。

上面是从 wiki 里粘贴出来的。

我举一个具体的例子。一个微服务对外提供接口,业务逻辑是一个聊天室

第一层:rpc handler

第二层:聊天室

第三层:聊天室中的人

第四层:聊天室中的人的消息

。。。

现在有这个一个需求,搜索消息中出现“xx”的消息。 那么按照这个定律去松耦合的话,要从第一层一直传到最后一层。。。 每一层都去下一层请求消息,这样感觉也是不对的。。。

又或者第一层想要直接获取聊天室中的,性别为男的人。 那么这个时候完全能够绕过第二层拿到信息的,是否也必须在第二层去创建一个函数(如果后续没有修改,那纯粹成透传了)。。。

这个怎么解决呢?

1243 次点击
所在节点    问与答
4 条回复
SWALLOWW
2020-09-07 09:59:42 +08:00
一个简单例子是,人可以命令一条狗行走( walk ),但是不应该直接指挥狗的腿行走,应该由狗去指挥控制它的腿如何行走。

这百度百科的例子不是很好理解吗,

你说的多层传递对于你来说是每层都写了方法,但是对于机器来说,就是一个方法,只不过多层指针跳转。其实对于设计来说,最主要是方便你的理解,当你不多层嵌套的时候,最外层需要对每层查询,如果你把这些方法都写在了最外层,对于维护和你之后的阅读都会很混乱的,就是面向对象思想吗,我是谁我就做什么事,别人的事我委托别人去做,
petelin
2020-09-07 14:44:10 +08:00
@SWALLOWW 我清楚你说的事情,但是实际写代码的时候,会发现,我知道有一条狗, 我也知道有一条狗有四条腿。
那我现在有个需求看那个狗腿上有伤。 那我是去在狗上写一个方法,还是直接在外面便利四条狗腿(狗腿上肯定有是否有伤的方法)。

那看起来肯定是在外面便利方便的多
SWALLOWW
2020-09-07 15:51:36 +08:00
@petelin
我觉得还是面向对象抽象出模型的能力,
你觉得应该在狗上面加一个查看伤的方法,但是正常从人的角度来说,狗并不会统计伤口并向你报告有几个伤口,所以我觉得应该抽象出一个人的对象,他去查看所有狗并统计狗的伤口,
说白了这个东西要符合你的认知才能觉得合理,你这样光套就拧巴了
SWALLOWW
2020-09-07 15:53:51 +08:00
@petelin 关于复杂度,如果很简单的结构,当然你在外面能获取所有狗腿会方便,但是如果结构很复杂,你怎么知道我应该在人 /狗 /狗舍 /狗腿哪个层面上去统计狗腿?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/704678

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX