『面试的底气』—— 设计模式之最少知识原则｜8月更文挑战

“这是我参与8月更文挑战的第3天，活动详情查看：8月更文挑战”

前言

在面试高级前端时，往往会遇到一些关于设计模式的问题，每次都回答不太理想。恰逢8月更文挑战的活动，准备用一个月时间好好理一下关于设计模式方面的知识点，给自己增加点面试的底气。

在学习设计模式之前，首先要认识到设计模式是个编程思想，对任何编程语言都适用。其次要从设计模式的原则开始学习，故本文将详细介绍设计模式的原则之一最少知识原则。

官方定义

最少知识原则也称迪米特法则，其含义是：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某个方法的话，可以通过第三者转发这个调用。

自己的理解

最少知识原则的英文是 The Least Knowledge Principle ，其中 Knowledge 这个单词也可以被翻译为知悉、了解、知道，个人认为最少知识原则应该被称为最少知道原则。

一个类对其它类知道的越少越好，就是说一个类应当对其他类有尽可能少的了解，只和朋友通信，不和陌生人说话，知道的越多，越麻烦。

用一个比较生动的例子来解释，有一天，研发部小张的电脑坏了，刚好小张认识IT部门的小王，于是叫小王帮忙修一下电脑，小王很快就过来了，检查了一番，给小张开了一个维修单，然后就把电脑带回办公室维修去了。小张等了好久，终于等不了了，直接去IT办公室，发现小王不在办公室，只好拿着维修单问小王的同事，得知小王有事出去了。小张问小王的同事：“我这边项目急需电脑处理一下问题，可不可以先帮我修一下”。小王的同事指着维修单上小王的签名，这是小王负责，不是我的事情，你等他回来吧。小张悻悻而去，回到办公室，小张跟同事小黄说起这件事情，感叹地说到：“如今这个社会，没熟人就是不好办事”。小黄听了这件事，直接说到：“你干嘛不找IT主管呢”？

上面的例子就是一个不遵循最少知识原则的典型例子。可以把上述例子的中的小张、小王、小王同事都当作一个类，小王和小王同事都有一个修电脑的方法，小张的父类是研发部主管，小王、小王同事的父类是IT部门主管。

小张电脑坏了，直接去调用小王的方法来修电脑，这就是违背最少知识原则，按最少知识原则的定义，小张和小王根本不需要认识，只需要认识IT部门主管，告诉IT部门主管说电脑坏了因项目需要紧急修复，IT部门主管自然知道轻重缓急回安排人去修复，就不会出现上述没熟人就是不好办事的情况。如果公司有使用OA系统，比如钉钉，直接发起维修申请单就可以，根本不需要认识IT部门主管。

把上述场景移植到程序中，就是中介模式的应用，其中IT部门主管或钉钉就是一个中介类。

再举一个生活中的例子，全自动洗衣机大家都很熟悉吧，现在越来越多洗衣机有一键洗衣的功能，按下一键洗衣后相当同时设置了浸泡、洗衣、漂洗、脱水4个步骤，可以直接洗衣服了。用户根本不需要去管浸泡、洗衣、漂洗、脱水4个步骤如何设置，当然也可以分别设置浸泡、洗衣、漂洗、脱水4个步骤后再洗衣服。这也是一个最少知识原则的应用，把上述场景移植到程序中，就是外观模式（门面模式）的应用，一键洗衣按键就是对洗衣机类中浸泡、洗衣、漂洗、脱水四个方法的封装。

作用

单一职责原则使得程序中的类高内聚，但越来越多的类之间可能会产生错综复杂的联系，如果修改了其中一个类，很可能会影响到跟它相互引用的其他类。类和类耦合在一起，有可能会降低它们的可复用性。在程序中，类的“朋友”太多并不是一件好事，“城门失火，殃及池鱼”和“一人犯法，株连九族”的故事时有发生。

所以最少知识原则就应运而生了，本人强烈觉得应该叫最少知道原则，知道的越少，麻烦越少。

其主要是为了类和类之间的解耦，使程序中的类实现高内聚低耦合。