阅读 1142

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

这是我参与8月更文挑战的第3天,活动详情查看:8月更文挑战

前言

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

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

官方定义

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

自己的理解

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

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

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

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

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

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

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

作用

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

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

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

文章分类
前端