作為一名合格的開發者，必須了解的編程原則有哪些？

目錄

通用

• KISS (Keep It Simple Stupid)

• YAGNI

• 做最簡單的事情

• 關注點分離

• 保持事情不再重復

• 為維護者寫代碼

• 避免過早優化

• 童子軍軍規

• 2021Java面試寶典

模塊間/類

• 最小化耦合

• 迪米特法則

• 組合優于繼承

• 正交性

• 穩健性原則

• 控制反轉

模塊/類

• 最大化聚合

• 里氏代換原則

• 開放/封閉原則

• 單一職責原則

• 隱藏實作細節

• 科里定律

• 封裝經常修改的代碼

• 介面隔離原則

• 命令查詢分離

KISS

大多數系統如果保持簡單而不是復雜，效果最好，

為什么

• 更少的代碼可以花更少的時間去寫，Bug更少，并且更容易修改，

• 簡單是復雜的最高境界，

• 完美境地，非冗雜，而不遺，

YAGNI

YAGNI的意思是“你不需要它”：在必要之前不要做多余的事情，

為什么

• 去做任何僅在未來需要的特性，意味著從當前迭代需要完成的功能中分出精力，

• 它使代碼膨脹；軟體變得更大和更復雜，

怎么做

• 在當你真正需要它們的時候，才實作它們，而不是在你預見到你需要它們的時候，

做最簡單的事情

為什么

• 僅有當我們只解決問題本身時，才能最大化地解決實際問題，

怎么做

• 捫心自問：“最簡單的事情是什么？”，

關注點分離

關注點分離是一種將計算機程式分離成不同部分的設計原則，以便每個部分專注于單個關注點，例如，應用程式的業務邏輯是一個關注點而用戶界面是另一個關注點，更改用戶界面不應要求更改業務邏輯，反之亦然，

參考Edsger W. Dijkstra (1974)所說：

我有時將其稱為“關注點分離”，即使這不可能完全做到，但它也是我所知道的唯一有效的思維整理技巧，這就是我所說的“將注意力集中在某個方面”的意思：這并不意味著忽略其他方面，只是對于從某一方面的視角公正地來看，另一方面是不相關的事情，

為什么

• 簡化軟體應用程式的開發與維護，

• 當關注點很好地分開時，各個部分可以被重用，并且可以獨立開發和更新，

怎么做

• 將程式功能分成聯系部分盡可能少的模塊，

保持事情不再重復

在一個系統內，每一項認識都必須有一個單一的、明確的、權威的表示，

程式中的每一項重要功能都應該只在源代碼中的一個地方實作，相似的函式由不同的代碼塊執行的情況下，抽象出不同的部分，將它們組合為一個函式通常是有益的，

為什么

• 重復（無意或有意的重復）會造成噩夢般的維護，保養不良和邏輯矛盾，

• 對系統中任意單個元素的修改不需要改變其他邏輯上無關的元素，

• 此外，相關邏輯的元素的變化都是可預測的和均勻的，因此是保持同步的，

怎么做

• 只在一個處撰寫業務規則、長運算式、if陳述句、數學公式、元資料等，

• 確定系統中使用的每一項認識的唯一來源，然后使用該源來生成該認識的適用實體（代碼、檔案、測驗等），

• 使用三法則（Rule of three）.

為維護者寫代碼

為什么

• 到目前為止，維護是任何專案中最昂貴的階段，

怎么做

• _成為_維護者，

• 不論何時撰寫代碼，要想著最后維護代碼的人是一個知道自己住在哪里的暴力精神病人，

• 如果某個入門的人掌握了代碼，他們就會從閱讀和學習代碼中獲得樂趣，以這樣的想法去撰寫代碼和注釋，

• 別讓我想（Don’t make me think）.

• 使用最少驚訝原則（Principle of Least Astonishment）.

避免過早優化

參考Donald Knuth所說：

程式員浪費大量的時間來思考或擔心程式的非關鍵部分的速度，而考研嘗試這些優化實際上在除錯和維護時有很強的負面影響，比如說在97%的開發時間，我們應該忽略低效率：過早的優化是萬惡之源，然而，我們不應該在關鍵的3%中放棄我們的機會，

當然，需要理解什么是“過早”什么不是“過早”，

為什么

• 瓶頸在哪是未知的，

• 優化后，閱讀和維護可能會更困難，

怎么做

• 使它運作，使它正確，使它更快（Make It Work Make It Right Make It Fast）

• 不要在你不需要的時候優化，只有在你發現一個瓶頸之后才能優化它，

最小化耦合

模塊/組件之間的耦合是它們互相依賴的程度，較低的耦合更好，換句話說，耦合是代碼單元“B”在未知的代碼單元“A”更改后“被破壞”的幾率，

為什么

• 一個模塊的更改通常會導致其他模塊的更改，產生漣漪效益，

• 由于模塊間的依賴性增加，模塊裝配可能需要更多的作業和/或時間，

• 特定的模塊可能難以重用和/或測驗，因為必須包含相關模塊，

• 開發人員可能害怕更改代碼，因為他們不確定什么會收到影響，

怎么做

• 消除，最小化和降低必要關聯的復雜性，

• 通過隱藏實作細節，減少耦合，

• 使用迪米特法則，

迪米特法則

不要和陌生人說話，

為什么

• 這通常會導致更緊密的耦合，

• 可能會暴露過多的實作細節，

怎么做

物件的方法只能呼叫以下方法：

1. 物件自身的方法，

2. 方法引數中的方法，

3. 方法中創建的任何物件的方法，

4. 物件的任何直接屬性或欄位的方法，

組合優于繼承

為什么

• 類之間的耦合減少，

• 使用繼承，子類很容易做出假設，并破壞里氏代換原則（LSP），

怎么做

• 測驗LSP（可替換性）以決定何時繼承，

• 當存在“有”（或“使用”）的關系時使用組合，當存在“是”的關系時使用繼承，

正交性

正交性的基本概念是，概念上不相關的東西在系統中不應該相關，

來源：Be Orthogonal

它越簡單，設計越正交，例外就越少，這使得用編程語言學習、讀寫程式變得更容易，正交特征的含義是獨立于環境；關鍵引數是對稱性與一致性，

來源：Orthogonality

穩健性原則

堅持保守自己的作為，自由接受他人的作為，

合作的服務依賴于彼此的介面，通常，介面需要提升，導致另一端接收未指定的資料，如果接收到的資料沒有嚴格遵守規范，那么簡單的實作將僅拒絕合作，更復雜的實作卻可以忽略它無法識別的資料，

為什么

• 為了能夠提高服務，你需要確保提供者可以進行更改以支持新的需求，同時對現有客戶端造成最小的破壞，

怎么做

• 向其他機器（或同一機器上的其他程式）發送指令或資料的代碼應該完全符合規范，但接受輸入的代碼應接受不一致的輸入，只要其意義明確，

控制反轉

控制反轉又被稱為好萊塢原則，“不要打電話給我們，我們會打電話給你”，它是一種設計原則，計算機程式的自定義撰寫部分從通用框架接收控制流，控制反轉具有強烈的含義，即可重用代碼和特定于問題的代碼是獨立開發的，即使它們在應用程式中一同作業，

為什么

• 控制反轉用于提高程式的模塊性，使其具有可擴展性，

• 將任務的執行與實作分離，

• 將模塊集中在其設計任務上，

• 使模塊不受關于其他系統如何執行其任務的假設約束，而是依賴于約定，

• 以防止模塊更換時出現副作用，

怎么做

• 使用工廠模式

• 使用服務定位器模式

• 使用依賴注入

• 使用依賴查找

• 使用模板方法模式

• 使用策略模式

最大化聚合

單個模塊/組件的聚合性是其職責形成有意義的單元的程度，越高的聚合性越好，

為什么

• 增加了理解模塊的難度，

• 增加了維護系統的難度，因為域中邏輯的更改會影響多個模塊，并且一個模塊的更改需要相關模塊的更改，

• 由于大多數應用程式不需要模塊提供的隨機操作集，因此重用模塊的難度增加，

怎么做

• 與組相關的功能共享一項職責（例如在一個類中），

里氏代換原則

里氏代換原則（LSP）完全是關于物件的預期行為：

程式中的物件應該可以替換為其子型別的實體，而不會改變該程式的正確性，

開放/封閉原則

軟體物體（例如類）應對擴展是開放的，但對修改是封閉的，也就是說，這樣的物體可以允許在不改變其源代碼的情況下修改其行為，

為什么

• 通過最小化對現有代碼的修改來提高可維護性和穩定性

怎么做

• 撰寫可以擴展的類（而不是可以修改的類）

• 只暴露需要更換的活動部分，隱藏其他所有部分，

單一職責原則

一個類不應該有多個修改的原因，

長話版：每個類都應該有一個單獨的職責，并且該職責應該完全由該類封裝，職責可以定義為修改的原因，一次類或模塊應該有且僅有一個修改的原因，

為什么

• 可維護性：僅有一個模塊或類中需要修改，

怎么做

• 使用 科里定律.

隱藏實作細節

軟體模塊通過提供介面來隱藏資訊（即實作細節），而不泄露任何不必要的資訊，

為什么

• 當實作更改時，客戶端使用的介面不必更改，

怎么做

• 最小化類和成員的可訪問性，

• 不要公開成員資料，

• 避免將私有實作細節放入類的介面中，

• 減少耦合以隱藏更多實作細節，

科里定律

科里定律是關于為任何特定代碼選擇一個明確定義的目標：僅做一件事，

• Curly’s Law: Do One Thing

• The Rule of One or Curly’s Law

封裝經常修改的代碼

一個好的設計可以辨別出最有可能改變的熱點，并將它們封裝在API之后，當預期的修改發生時，修改會保持在區域，

為什么

• 在發生更改時，最小化所需的修改，

怎么做

• 封裝API背后不同的概念，

• 將可能不同的概念分到各自的模塊，

介面隔離原則

將臃腫的介面減少到多個更小更具體的客戶端特定介面中，介面應該比實作它的代碼更依賴于呼叫它的代碼，

為什么

• 如果類實作了不需要的方法，則呼叫方需要了解該類的方法實作，例如，如果一個類實作了一個方法，但只是簡單的拋出例外，那么呼叫方將需要知道實際上不應該呼叫這個方法，

怎么做

• 避免臃腫的介面，類不應該實作任何違反單一職責原則的方法，

童子軍軍規

美國童子軍有一條簡單的軍規，我們可以使用到我們的職業中：“離開營地時比你到達時更干凈”，根據童子軍軍規，我們應該至終保持代碼比我們看到時更干凈，

為什么

• 當對現有代碼庫進行更改時，代碼質量往往會降低，從而積累技術債務，根據童子軍軍規，我們應該注意每一個提交（Commit）的質量，無論規模有多小，技術債務都會受到不斷重構的抵制，

怎么做

• 每次提交都要確保它不會降低代碼庫的質量，

• 任何時候，如果有人看到一些代碼不夠清楚，他們就應該抓住機會在那里修復它，

命令查詢分離

命令查詢分離原則規定，每個方法都應該是執行操作的命令，或者是向呼叫者回傳資料但不能同時做兩件事的查詢，提問不應該改變答案，

利用這個原則，程式員可以更加自信地進行編碼，查詢方法可以在任何地方以任何順序使用，因為它們不會改變狀態，而使用命令，你必須更加小心，

為什么

• 通過將方法清晰地分為查詢和命令，程式員可以在不了解每個方法的實作細節的情況下，更加自信地編碼，

怎么做

• 將每個方法實作為查詢或命令，2021Java面試寶典

• 對方法名使用命名約定，該方法名表示該方法是查詢還是命令，

標籤：Java

上一篇：2021最新 Spring面試題精選（附刷題小程式）

下一篇：redis集群