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

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

前言

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

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

官方定义

最少知识原则也称迪米特法则，其含义是：若是两个类没必要彼此直接通讯，那么这两个类就不该当发生直接的相互做用。若是其中一个类须要调用另外一个类的某个方法的话，能够经过第三者转发这个调用。

本身的理解

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

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

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

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

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

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

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

做用

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

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

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