趣解设计模式之《只是买台咖啡机，竟要我去学习咖啡器的运行原理？》
〇、小故事
小王最近工作特别的忙，每天要早出晚归，睡眠质量很差，为了可以精力充沛的投入到每天的工作中，她都在上班路上买一杯公司楼下的星巴克咖啡来提提神。咖啡味道很好，但是每天买咖啡的人真的是太多了，本来上班的路上就已经很疲劳了，还要在店门口排半天的队，她觉得这种情况需要改变一下了。
那么既然早上要喝杯咖啡来提提神，何不自己买台咖啡机呢？早上起来，吃完早饭，喝杯自己做的咖啡，岂不美哉！于是乎，她就从网上买了一台咖啡机，她找了半天说明书，结果就找到一个客服电话，她打电话过去咨询为什么没有说明书？客户妹妹说，不需要说明书的，您可以参加我们的免费培训课程，一共20节课，我们会从原理上给您讲解咖啡机是工作原理的！
“什么！我只是买台咖啡机，竟然要学习咖啡器的运行原理？”你们公司莫不是疯了吧。挂掉电话后，小王就把这款咖啡机退掉了……（虚拟故事，莫要当真~）
一、原则定义
通过上面的故事，大家肯定也会觉得非常的荒谬。我买一台咖啡机，你就告诉我怎么使用就可以了呗！干嘛要我去学习你们咖啡机的工作原理呢！那难道我买一台汽车，我还要学习汽车工作原理吗！
所以，在日常生活中，迪米特法则就已经融入到我们的生活中了。那么，到底什么是迪米特法则呢？我们来看一下它的定义：
LoD（
Law of Demeter）：也称为最少知识原则。描述的是：一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂，那是你的事儿，和我没关系，我就知道你提供的这么多方法，我就调用这么多，其他的我一概不关系。
那么，还是以买咖啡机为例，我们买了一款咖啡机，只需要根据说明书，知道怎么制作一杯香浓的咖啡即可，其他的我就不关注了。这也就是日常生活中的迪米特法则/最少知识原则；
而在我们开发的时候，也需要遵循这个设计原则。比如我们常常在开发过程中，需要调用其他研发团队的接口，来实现某种业务逻辑，我们以支付为例。作为我们使用方，只需要对方提供一个支付接口，调用后返回支付成功或支付失败&失败原因即可。如果对方开发人员给了你2,3个接口，让你按照某些支付流程去调用，这显然就违背了迪米特法则了。你应该立刻针对其中的不合理性进行讨论，而不是听之任之。
二、原则实践
上面的故事和原理相信大家都已经有所了解了，我们还是举一个业务上的小例子，再来加深说明一下违反里式替换后可能会出现的问题。
业务背景：
当一个微信用户要在我们系统操作业务逻辑的时候，我们的需求是： 【1】如果微信用户没有注册我们系统的话，我们默认的调用注册接口去注册它，注册成功后，把用户信息返回给业务系统； 【2】如果她已经注册了，即已经存在于我们的用户表，则把用户信息返回给业务系统，再通过它的用户信息，进行下一步业务操作。 那么针对于这个需求，我们其实应该是希望负责用户信息的研发团队，给我们提供一个接口，即：获得用户信息的接口。而不应该提供用户信息查询接口，用户信息注册接口，甚至底层还涉及到其他安全性接口，由我们一步一步的去调用，这样就违反了迪米特法则了。
以上做法类似DDD里面领域划分的概念。是我域负责的业务我负责，不是我域的业务，由相关领域负责即可。