『面試的底氣』—— 設計模式之最少知識原則｜8月更文挑戰

「這是我參與8月更文挑戰的第3天，活動詳情查看：8月更文挑戰」

前言

在面試高級前端時，每每會遇到一些關於設計模式的問題，每次都回答不太理想。恰逢8月更文挑戰的活動，準備用一個月時間好好理一下關於設計模式方面的知識點，給本身增長點面試的底氣。

在學習設計模式以前，首先要認識到設計模式是個編程思想，對任何編程語言都適用。其次要從設計模式的原則開始學習，故本文將詳細介紹設計模式的原則之一最少知識原則。

官方定義

最少知識原則也稱迪米特法則，其含義是：若是兩個類沒必要彼此直接通訊，那麼這兩個類就不該當發生直接的相互做用。若是其中一個類須要調用另外一個類的某個方法的話，能夠經過第三者轉發這個調用。

本身的理解

最少知識原則的英文是 The Least Knowledge Principle ，其中 Knowledge 這個單詞也能夠被翻譯爲知悉、瞭解、知道，我的認爲最少知識原則應該被稱爲最少知道原則。

一個類對其它類知道的越少越好，就是說一個類應當對其餘類有儘量少的瞭解，只和朋友通訊，不和陌生人說話，知道的越多，越麻煩。

用一個比較生動的例子來解釋，有一天，研發部小張的電腦壞了，恰好小張認識IT部門的小王，因而叫小王幫忙修一下電腦，小王很快就過來了，檢查了一番，給小張開了一個維修單，而後就把電腦帶回辦公室維修去了。小張等了很久，終於等不了了，直接去IT辦公室，發現小王不在辦公室，只好拿着維修單問小王的同事，得知小王有事出去了。小張問小王的同事：「我這邊項目急需電腦處理一下問題，可不能夠先幫我修一下」。小王的同事指着維修單上小王的簽名，這是小王負責，不是個人事情，你等他回來吧。小張悻悻而去，回到辦公室，小張跟同事小黃提及這件事情，感嘆地說到：「現在這個社會，沒熟人就是很差辦事」。小黃聽了這件事，直接說到：「你幹嗎不找IT主管呢」？

上面的例子就是一個不遵循最少知識原則的典型例子。能夠把上述例子的中的小張、小王、小王同事都看成一個類，小王和小王同事都有一個修電腦的方法，小張的父類是研發部主管，小王、小王同事的父類是IT部門主管。

小張電腦壞了，直接去調用小王的方法來修電腦，這就是違背最少知識原則，按最少知識原則的定義，小張和小王根本不須要認識，只須要認識IT部門主管，告訴IT部門主管說電腦壞了因項目須要緊急修復，IT部門主管天然知道輕重緩急回安排人去修復，就不會出現上述沒熟人就是很差辦事的狀況。若是公司有使用OA系統，好比釘釘，直接發起維修申請單就能夠，根本不須要認識IT部門主管。

把上述場景移植到程序中，就是中介模式的應用，其中IT部門主管或釘釘就是一箇中介類。

再舉一個生活中的例子，全自動洗衣機你們都很熟悉吧，如今愈來愈多洗衣機有一鍵洗衣的功能，按下一鍵洗衣後至關同時設置了浸泡、洗衣、漂洗、脫水4個步驟，能夠直接洗衣服了。用戶根本不須要去管浸泡、洗衣、漂洗、脫水4個步驟如何設置，固然也能夠分別設置浸泡、洗衣、漂洗、脫水4個步驟後再洗衣服。這也是一個最少知識原則的應用，把上述場景移植到程序中，就是外觀模式（門面模式）的應用，一鍵洗衣按鍵就是對洗衣機類中浸泡、洗衣、漂洗、脫水四個方法的封裝。

做用

單一職責原則使得程序中的類高內聚，但愈來愈多的類之間可能會產生錯綜複雜的聯繫，若是修改了其中一個類，極可能會影響到跟它相互引用的其餘類。類和類耦合在一塊兒，有可能會下降它們的可複用性。在程序中，類的「朋友」太多並非一件好事，「城門失火，殃及池魚」和「一人犯法，株連九族」的故事時有發生。

因此最少知識原則就應運而生了，本人強烈以爲應該叫最少知道原則，知道的越少，麻煩越少。

其主要是爲了類和類之間的解耦，使程序中的類實現高內聚低耦合。