編程原則

本文來源：http://r6d.cn/N3Sz

「

本文翻譯自Programming Principles。

每一個程序員均可以從理解編程原理和模式中受益。這篇概述用於我我的參考，同時我也把它放在這。也許這在設計、討論或複查中對你有所幫助。但請注意，這還遠遠不夠，你經常須要在相互矛盾的原則之間作出權衡。

本文受The Principles of Good Programming啓發。我以爲這份列表已經足夠了，但這並不徹底符合我我的的想法。此外，我還須要更多的論證、細節以及其餘資料的連接。若是您有任何反饋或者改進的建議，請讓我知道。

目錄

通用

• KISS (Keep It Simple Stupid)
• YAGNI
• 作最簡單的事情
• 關注點分離
• 保持事情再也不重複
• 爲維護者寫代碼
• 避免過早優化
• 童子軍軍規

模塊間/類

• 最小化耦合
• 迪米特法則
• 組合優於繼承
• 正交性
• 穩健性原則
• 控制反轉

模塊/類

• 最大化聚合
• 里氏代換原則
• 開放/封閉原則
• 單一職責原則
• 隱藏實現細節
• 科裏定律
• 封裝常常修改的代碼
• 接口隔離原則
• 命令查詢分離

KISS

大多數系統若是保持簡單而不是複雜，效果最好。

爲何

• 更少的代碼能夠花更少的時間去寫，Bug更少，而且更容易修改。
• 簡單是複雜的最高境界。
• 完美境地，非冗雜，而不遺。

相關資料

• KISS principle
• Keep It Simple Stupid (KISS)

YAGNI

YAGNI的意思是「你不須要它」：在必要以前不要作多餘的事情。

爲何

• 去作任何僅在將來須要的特性，意味着從當前迭代須要完成的功能中分出精力。
• 它使代碼膨脹；軟件變得更大和更復雜。

怎麼作

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

相關資料

• You Arent Gonna Need It
• You’re NOT gonna need it!
• You ain’t gonna need it

作最簡單的事情

爲何

• 僅有當咱們只解決問題自己時，才能最大化地解決實際問題。

怎麼作

• 捫心自問：「最簡單的事情是什麼？」。

相關資料

• Do The Simplest Thing That Could Possibly Work

關注點分離

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

引用Edsger W. Dijkstra (1974)所說：

「

我有時將其稱爲「關注點分離」，即便這不可能徹底作到，但它也是我所知道的惟一有效的思惟整理技巧。這就是我所說的「將注意力集中在某個方面」的意思：這並不意味着忽略其餘方面，只是對於從某一方面的視角公正地來看，另外一方面是不相關的事情。

爲何

• 簡化軟件應用程序的開發與維護。
• 當關注點很好地分開時，各個部分能夠被重用，而且能夠獨立開發和更新。

怎麼作

• 將程序功能分紅聯繫部分儘量少的模塊。

相關資料

• Separation of Concerns

保持事情再也不重複

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

程序中的每一項重要功能都應該只在源代碼中的一個地方實現。類似的函數由不一樣的代碼塊執行的狀況下，抽象出不一樣的部分，將它們組合爲一個函數一般是有益的。

爲何

• 重複（無心或有意的重複）會形成噩夢般的維護，保養不良和邏輯矛盾。
• 對系統中任意單個元素的修改不須要改變其餘邏輯上無關的元素。
• 此外，相關邏輯的元素的變化都是可預測的和均勻的，所以是保持同步的。

怎麼作

• 只在一個處編寫業務規則、長表達式、if語句、數學公式、元數據等。
• 肯定系統中使用的每一項認識的惟一來源，而後使用該源來生成該認識的適用實例（代碼、文檔、測試等）。
• 使用三法則（Rule of three）.

相關資料

• Dont Repeat Yourself
• Don’t repeat yourself
• Don’t Repeat Yourself

類似資料

• Abstraction principle
• Once And Only Once is a subset of DRY (also referred to as the goal of refactoring).
• Single Source of Truth
• A violation of DRY is WET (Write Everything Twice)

爲維護者寫代碼

爲何

• 到目前爲止，維護是任何項目中最昂貴的階段。

怎麼作

• 成爲維護者。
• 不論什麼時候編寫代碼，要想着最後維護代碼的人是一個知道本身住在哪裏的暴力精神病人。
• 若是某個入門的人掌握了代碼，他們就會從閱讀和學習代碼中得到樂趣，以這樣的想法去編寫代碼和註釋。
• 別讓我想（Don’t make me think）.
• 使用最少驚訝原則（Principle of Least Astonishment）.

相關資料

• Code For The Maintainer
• The Noble Art of Maintenance Programming

避免過早優化

引用Donald Knuth所說：

「

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

固然，須要理解什麼是「過早」什麼不是「過早」。

爲何

• 瓶頸在哪是未知的。
• 優化後，閱讀和維護可能會更困難。

怎麼作

• 使它運做，使它正確，使它更快（Make It Work Make It Right Make It Fast）
• 不要在你不須要的時候優化，只有在你發現一個瓶頸以後才能優化它。

相關資料

• Program optimization
• Premature Optimization

最小化耦合

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

爲何

• 一個模塊的更改一般會致使其餘模塊的更改，產生漣漪效益。
• 因爲模塊間的依賴性增長，模塊裝配可能須要更多的工做和/或時間。
• 特定的模塊可能難以重用和/或測試，由於必須包含相關模塊。
• 開發人員可能懼怕更改代碼，由於他們不肯定什麼會收到影響。

怎麼作

• 消除，最小化和下降必要關聯的複雜性。
• 經過隱藏實現細節，減小耦合。
• 使用迪米特法則。

相關資料

• Coupling
• Coupling And Cohesion

迪米特法則

不要和陌生人說話。

爲何

• 這一般會致使更緊密的耦合。
• 可能會暴露過多的實現細節。

怎麼作

對象的方法只能調用如下方法：

1. 對象自身的方法。
2. 方法參數中的方法。
3. 方法中建立的任何對象的方法。
4. 對象的任何直接屬性或字段的方法。

相關資料

• Law of Demeter
• The Law of Demeter Is Not A Dot Counting Exercise

組合優於繼承

爲何

• 類之間的耦合減小。
• 使用繼承，子類很容易作出假設，並破壞里氏代換原則（LSP）。

怎麼作

• 測試LSP（可替換性）以決定什麼時候繼承。
• 當存在「有」（或「使用」）的關係時使用組合，當存在「是」的關係時使用繼承。

相關資料

• Favor Composition Over Inheritance

正交性

「

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

來源：Be Orthogonal

「

它越簡單，設計越正交，異常就越少。這使得用編程語言學習、讀寫程序變得更容易。正交特徵的含義是獨立於環境；關鍵參數是對稱性與一致性。

來源：Orthogonality

穩健性原則

「

堅持保守本身的做爲，自由接受他人的做爲。

合做的服務依賴於彼此的接口。一般，接口須要提高，致使另外一端接收未指定的數據。若是接收到的數據沒有嚴格遵照規範，那麼簡單的實現將僅拒絕合做。更復雜的實現卻能夠忽略它沒法識別的數據。

爲何

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

怎麼作

• 向其餘機器（或同一機器上的其餘程序）發送指令或數據的代碼應該徹底符合規範，但接受輸入的代碼應接受不一致的輸入，只要其意義明確。

相關資料

• Robustness Principle in Wikipedia
• Tolerant Reader

控制反轉

控制反轉又被稱爲好萊塢原則，「不要打電話給咱們，咱們會打電話給你」。它是一種設計原則，計算機程序的自定義編寫部分從通用框架接收控制流。控制反轉具備強烈的含義，便可重用代碼和特定於問題的代碼是獨立開發的，即便它們在應用程序中一同工做。

爲何

• 控制反轉用於提升程序的模塊性，使其具備可擴展性。
• 將任務的執行與實現分離。
• 將模塊集中在其設計任務上。
• 使模塊不受關於其餘系統如何執行其任務的假設約束，而是依賴於約定。
• 以防止模塊更換時出現反作用。

怎麼作

• 使用工廠模式
• 使用服務定位器模式
• 使用依賴注入
• 使用依賴查找
• 使用模板方法模式
• 使用策略模式

相關資料

• Inversion of Control in Wikipedia
• Inversion of Control Containers and the Dependency Injection pattern

最大化聚合

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

爲何

• 增長了理解模塊的難度。
• 增長了維護系統的難度，由於域中邏輯的更改會影響多個模塊，而且一個模塊的更改須要相關模塊的更改。
• 因爲大多數應用程序不須要模塊提供的隨機操做集，所以重用模塊的難度增長。

怎麼作

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

相關資料

• Cohesion
• Coupling And Cohesion

里氏代換原則

里氏代換原則（LSP）徹底是關於對象的預期行爲：

「

程序中的對象應該能夠替換爲其子類型的實例，而不會改變該程序的正確性。

相關資源

• Liskov substitution principle
• Liskov Substitution Principle

開放/封閉原則

軟件實體（例如類）應對擴展是開放的，但對修改是封閉的。也就是說，這樣的實體能夠容許在不改變其源代碼的狀況下修改其行爲。

爲何

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

怎麼作

• 編寫能夠擴展的類（而不是能夠修改的類）
• 只暴露須要更換的活動部分，隱藏其餘全部部分。

相關資源

• Open Closed Principle
• The Open Closed Principle

單一職責原則

一個類不該該有多個修改的緣由。

長話版：每一個類都應該有一個單獨的職責，而且該職責應該徹底由該類封裝。職責能夠定義爲修改的緣由，一次類或模塊應該有且僅有一個修改的緣由。

爲何

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

怎麼作

• 使用 科裏定律.

相關資料

• Single responsibility principle

隱藏實現細節

軟件模塊經過提供接口來隱藏信息（即實現細節），而不泄露任何沒必要要的信息。

爲何

• 當實現更改時，客戶端使用的接口沒必要更改。

怎麼作

• 最小化類和成員的可訪問性。
• 不要公開成員數據。
• 避免將私有實現細節放入類的接口中。
• 減小耦合以隱藏更多實現細節。

相關資料

• Information hiding

科裏定律

科裏定律是關於爲任何特定代碼選擇一個明肯定義的目標：僅作一件事。

• Curly’s Law: Do One Thing
• The Rule of One or Curly’s Law

封裝常常修改的代碼

一個好的設計能夠辨別出最有可能改變的熱點，並將它們封裝在API以後。當預期的修改發生時，修改會保持在局部。

爲何

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

怎麼作

• 封裝API背後不一樣的概念。
• 將可能不一樣的概念分到各自的模塊。

相關資料

• Encapsulate the Concept that Varies
• Encapsulate What Varies
• Information Hiding

接口隔離原則

將臃腫的接口減小到多個更小更具體的客戶端特定接口中。接口應該比實現它的代碼更依賴於調用它的代碼。

爲何

• 若是類實現了不須要的方法，則調用方須要瞭解該類的方法實現。例如，若是一個類實現了一個方法，但只是簡單的拋出異常，那麼調用方將須要知道實際上不該該調用這個方法。

怎麼作

• 避免臃腫的接口。類不該該實現任何違反單一職責原則的方法。

相關資料

• Interface segregation principle

童子軍軍規

美國童子軍有一條簡單的軍規，咱們可使用到咱們的職業中：「離開營地時比你到達時更乾淨」。根據童子軍軍規，咱們應該至終保持代碼比咱們看到時更乾淨。

爲何

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

怎麼作

• 每次提交都要確保它不會下降代碼庫的質量。
• 任什麼時候候，若是有人看到一些代碼不夠清楚，他們就應該抓住機會在那裏修復它。

相關資料

• Opportunistic Refactoring

命令查詢分離

命令查詢分離原則規定，每一個方法都應該是執行操做的命令，或者是向調用者返回數據但不能同時作兩件事的查詢。提問不該該改變答案。

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

爲何

• 經過將方法清晰地分爲查詢和命令，程序員能夠在不瞭解每一個方法的實現細節的狀況下，更加自信地編碼。

怎麼作

• 將每一個方法實現爲查詢或命令。
• 對方法名使用命名約定，該方法名錶示該方法是查詢仍是命令。

相關資料

• Command Query Separation in Wikipedia
• Command Query Separation by Martin Fowler

---

本文分享自微信公衆號 - 肥朝（feichao_java）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。