未分類
7 9 月 2020

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

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

資深大佬 : petelin 1

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”的消息。 那么按照这个定律去松耦合的话，要从第一层一直传到最后一层。。。 每一层都去下一层请求消息，这样感觉也是不对的。。。

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

这个怎么解决呢？

大佬有話說 (4)

  • 資深大佬 : SWALLOWW

    一个简单例子是，人可以命令一条狗行走（ walk ），但是不应该直接指挥狗的腿行走，应该由狗去指挥控制它的腿如何行走。

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

    你说的多层传递对于你来说是每层都写了方法，但是对于机器来说，就是一个方法，只不过多层指针跳转。其实对于设计来说，最主要是方便你的理解，当你不多层嵌套的时候，最外层需要对每层查询，如果你把这些方法都写在了最外层，对于维护和你之后的阅读都会很混乱的，就是面向对象思想吗，我是谁我就做什么事，别人的事我委托别人去做，

  • 主 資深大佬 : petelin

    @SWALLOWW 我清楚你说的事情，但是实际写代码的时候，会发现，我知道有一条狗， 我也知道有一条狗有四条腿。
    那我现在有个需求看那个狗腿上有伤。 那我是去在狗上写一个方法，还是直接在外面便利四条狗腿（狗腿上肯定有是否有伤的方法）。

    那看起来肯定是在外面便利方便的多

  • 資深大佬 : SWALLOWW

    @petelin
    我觉得还是面向对象抽象出模型的能力，
    你觉得应该在狗上面加一个查看伤的方法，但是正常从人的角度来说，狗并不会统计伤口并向你报告有几个伤口，所以我觉得应该抽象出一个人的对象，他去查看所有狗并统计狗的伤口，
    说白了这个东西要符合你的认知才能觉得合理，你这样光套就拧巴了

  • 資深大佬 : SWALLOWW

    @petelin 关于复杂度，如果很简单的结构，当然你在外面能获取所有狗腿会方便，但是如果结构很复杂，你怎么知道我应该在人 /狗 /狗舍 /狗腿哪个层面上去统计狗腿？