超級干貨：你應該知道的那些編程原則！！
本文翻譯自Programming Principles(http://java-design-patterns.com/principles/)。
每個程序員都可以從理解編程原理和模式中受益。這篇概述用于我個人參考，同時我也把它放在這。也許這在設計、討論或復查中對你有所幫助。但請注意，這還遠遠不夠，你常常需要在相互矛盾的原則之間做出權衡。
本文受The Principles of Good Programming(http://www.artima.com/weblogs/viewpost.jsp?thread=331531)啟發(fā)。我覺得這份列表已經(jīng)足夠了，但這并不完全符合我個人的想法。此外，我還需要更多的論證、細節(jié)以及其他資料的鏈接。
KISS
大多數(shù)系統(tǒng)如果保持簡單而不是復雜，效果最好。
為什么
更少的代碼可以花更少的時間去寫，Bug更少，并且更容易修改。 簡單是復雜的最高境界。 完美境地，非冗雜，而不遺。
相關資料
KISS principle(http://en.wikipedia.org/wiki/KISS_principle) Keep It Simple Stupid (KISS)(http://principles-wiki.net/principles:keep_it_simple_stupid)
YAGNI
YAGNI的意思是“你不需要它”：在必要之前不要做多余的事情。
為什么
去做任何僅在未來需要的特性，意味著從當前迭代需要完成的功能中分出精力。 它使代碼膨脹；軟件變得更大和更復雜。
怎么做
在當你真正需要它們的時候，才實現(xiàn)它們，而不是在你預見到你需要它們的時候。
相關資料
You Arent Gonna Need It(http://c2.com/xp/YouArentGonnaNeedIt.html) You’re NOT gonna need it!(http://www.xprogramming.com/Practices/PracNotNeed.html) You ain’t gonna need it(http://en.wikipedia.org/wiki/You_ain't_gonna_need_it)
做最簡單的事情
為什么
僅有當我們只解決問題本身時，才能最大化地解決實際問題。
怎么做
捫心自問：“最簡單的事情是什么？”。
相關資料
Do The Simplest Thing That Could Possibly Work(http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html)
關注點分離
關注點分離是一種將計算機程序分離成不同部分的設計原則，以便每個部分專注于單個關注點。例如，應用程序的業(yè)務邏輯是一個關注點而用戶界面是另一個關注點。更改用戶界面不應要求更改業(yè)務邏輯，反之亦然。
引用Edsger W. Dijkstra(https://en.wikipedia.org/wiki/Edsger_W._Dijkstra) (1974)所說：
我有時將其稱為“關注點分離”，即使這不可能完全做到，但它也是我所知道的唯一有效的思維整理技巧。這就是我所說的“將注意力集中在某個方面”的意思：這并不意味著忽略其他方面，只是對于從某一方面的視角公正地來看，另一方面是不相關的事情。
為什么
簡化軟件應用程序的開發(fā)與維護。 當關注點很好地分開時，各個部分可以被重用，并且可以獨立開發(fā)和更新。
怎么做
將程序功能分成聯(lián)系部分盡可能少的模塊。
相關資料
Separation of Concerns(https://en.wikipedia.org/wiki/Separation_of_concerns)
保持事情不再重復
在一個系統(tǒng)內(nèi)，每一項認識都必須有一個單一的、明確的、權威的表示。
程序中的每一項重要功能都應該只在源代碼中的一個地方實現(xiàn)。相似的函數(shù)由不同的代碼塊執(zhí)行的情況下，抽象出不同的部分，將它們組合為一個函數(shù)通常是有益的。
為什么
重復（無意或有意的重復）會造成噩夢般的維護，保養(yǎng)不良和邏輯矛盾。 對系統(tǒng)中任意單個元素的修改不需要改變其他邏輯上無關的元素。 此外，相關邏輯的元素的變化都是可預測的和均勻的，因此是保持同步的。
怎么做
只在一個處編寫業(yè)務規(guī)則、長表達式、if語句、數(shù)學公式、元數(shù)據(jù)等。 確定系統(tǒng)中使用的每一項認識的唯一來源，然后使用該源來生成該認識的適用實例（代碼、文檔、測試等）。 使用三法則（Rule of three）(http://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)).
相關資料
Dont Repeat Yourself(http://c2.com/cgi/wiki?DontRepeatYourself) Don’t repeat yourself(http://en.wikipedia.org/wiki/Don't_repeat_yourself) Don’t Repeat Yourself(http://programmer.97things.oreilly.com/wiki/index.php/Don't_Repeat_Yourself)
相似資料
Abstraction principle(http://en.wikipedia.org/wiki/Abstraction_principle_(computer_programming)) Once And Only Once(http://c2.com/cgi/wiki?OnceAndOnlyOnce) is a subset of DRY (also referred to as the goal of refactoring). Single Source of Truth(http://en.wikipedia.org/wiki/Single_Source_of_Truth) A violation of DRY is WET(http://thedailywtf.com/articles/The-WET-Cart) (Write Everything Twice)
為維護者寫代碼
為什么
到目前為止，維護是任何項目中最昂貴的階段。
怎么做
成為維護者。 不論何時編寫代碼，要想著最后維護代碼的人是一個知道自己住在哪里的暴力精神病人。 如果某個入門的人掌握了代碼，他們就會從閱讀和學習代碼中獲得樂趣，以這樣的想法去編寫代碼和注釋。 別讓我想（Don’t make me think）(http://www.sensible.com/dmmt.html). 使用最少驚訝原則（Principle of Least Astonishment）(http://en.wikipedia.org/wiki/Principle_of_least_astonishment).
相關資料
Code For The Maintainer(http://c2.com/cgi/wiki?CodeForTheMaintainer) The Noble Art of Maintenance Programming(http://blog.codinghorror.com/the-noble-art-of-maintenance-programming/)
避免過早優(yōu)化
引用Donald Knuth(http://en.wikiquote.org/wiki/Donald_Knuth)所說：
程序員浪費大量的時間來思考或擔心程序的非關鍵部分的速度，而考研嘗試這些優(yōu)化實際上在調(diào)試和維護時有很強的負面影響。比如說在97%的開發(fā)時間，我們應該忽略低效率：過早的優(yōu)化是萬惡之源。然而，我們不應該在關鍵的3%中放棄我們的機會。
當然，需要理解什么是“過早”什么不是“過早”。
為什么
瓶頸在哪是未知的。 優(yōu)化后，閱讀和維護可能會更困難。
怎么做
使它運作，使它正確，使它更快（Make It Work Make It Right Make It Fast）(http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast) 不要在你不需要的時候優(yōu)化，只有在你發(fā)現(xiàn)一個瓶頸之后才能優(yōu)化它。
相關資料
Program optimization(http://en.wikipedia.org/wiki/Program_optimization) Premature Optimization(http://c2.com/cgi/wiki?PrematureOptimization)
最小化耦合
模塊/組件之間的耦合是它們互相依賴的程度，較低的耦合更好。換句話說，耦合是代碼單元“B”在未知的代碼單元“A”更改后“被破壞”的幾率。
為什么
一個模塊的更改通常會導致其他模塊的更改，產(chǎn)生漣漪效益。 由于模塊間的依賴性增加，模塊裝配可能需要更多的工作和/或時間。 特定的模塊可能難以重用和/或測試，因為必須包含相關模塊。 開發(fā)人員可能害怕更改代碼，因為他們不確定什么會收到影響。
怎么做
消除，最小化和降低必要關聯(lián)的復雜性。 通過隱藏實現(xiàn)細節(jié)，減少耦合。 使用迪米特法則(https://mouse0w0.github.io/2018/10/04/Programming-Principles/#迪米特法則)。
相關資料
Coupling(http://en.wikipedia.org/wiki/Coupling_(computer_programming)) Coupling And Cohesion(http://c2.com/cgi/wiki?CouplingAndCohesion)
迪米特法則
不要和陌生人說話。
為什么
這通常會導致更緊密的耦合。 可能會暴露過多的實現(xiàn)細節(jié)。
怎么做
對象的方法只能調(diào)用以下方法：
對象自身的方法。 方法參數(shù)中的方法。 方法中創(chuàng)建的任何對象的方法。 對象的任何直接屬性或字段的方法。
相關資料
Law of Demeter(http://en.wikipedia.org/wiki/Law_of_Demeter) The Law of Demeter Is Not A Dot Counting Exercise(http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx/)
組合優(yōu)于繼承
為什么
類之間的耦合減少。 使用繼承，子類很容易做出假設，并破壞里氏代換原則（LSP）。
怎么做
測試LSP（可替換性）以決定何時繼承。 當存在“有”（或“使用”）的關系時使用組合，當存在“是”的關系時使用繼承。
相關資料
Favor Composition Over Inheritance(http://blogs.msdn.com/b/thalesc/archive/2012/09/05/favor-composition-over-inheritance.aspx)
正交性
正交性的基本概念是，概念上不相關的東西在系統(tǒng)中不應該相關。
來源：Be Orthogonal(http://www.artima.com/intv/dry3.html)
它越簡單，設計越正交，異常就越少。這使得用編程語言學習、讀寫程序變得更容易。正交特征的含義是獨立于環(huán)境；關鍵參數(shù)是對稱性與一致性。
來源：Orthogonality
穩(wěn)健性原則
堅持保守自己的作為，自由接受他人的作為。
合作的服務依賴于彼此的接口。通常，接口需要提升，導致另一端接收未指定的數(shù)據(jù)。如果接收到的數(shù)據(jù)沒有嚴格遵守規(guī)范，那么簡單的實現(xiàn)將僅拒絕合作。更復雜的實現(xiàn)卻可以忽略它無法識別的數(shù)據(jù)。
為什么
為了能夠提高服務，你需要確保提供者可以進行更改以支持新的需求，同時對現(xiàn)有客戶端造成最小的破壞。
怎么做
向其他機器（或同一機器上的其他程序）發(fā)送指令或數(shù)據(jù)的代碼應該完全符合規(guī)范，但接受輸入的代碼應接受不一致的輸入，只要其意義明確。
相關資料
Robustness Principle in Wikipedia(https://en.wikipedia.org/wiki/Robustness_principle) Tolerant Reader(http://martinfowler.com/bliki/TolerantReader.html)
控制反轉
控制反轉又被稱為好萊塢原則，“不要打電話給我們，我們會打電話給你”。它是一種設計原則，計算機程序的自定義編寫部分從通用框架接收控制流?？刂品崔D具有強烈的含義，即可重用代碼和特定于問題的代碼是獨立開發(fā)的，即使它們在應用程序中一同工作。
為什么
控制反轉用于提高程序的模塊性，使其具有可擴展性。 將任務的執(zhí)行與實現(xiàn)分離。 將模塊集中在其設計任務上。 使模塊不受關于其他系統(tǒng)如何執(zhí)行其任務的假設約束，而是依賴于約定。 以防止模塊更換時出現(xiàn)副作用。
怎么做
使用工廠模式 使用服務定位器模式 使用依賴注入 使用依賴查找 使用模板方法模式 使用策略模式
相關資料
Inversion of Control in Wikipedia(https://en.wikipedia.org/wiki/Inversion_of_control) Inversion of Control Containers and the Dependency Injection pattern(https://www.martinfowler.com/articles/injection.html)
最大化聚合
單個模塊/組件的聚合性是其職責形成有意義的單元的程度，越高的聚合性越好。
為什么
增加了理解模塊的難度。 增加了維護系統(tǒng)的難度，因為域中邏輯的更改會影響多個模塊，并且一個模塊的更改需要相關模塊的更改。 由于大多數(shù)應用程序不需要模塊提供的隨機操作集，因此重用模塊的難度增加。
怎么做
與組相關的功能共享一項職責（例如在一個類中）。
相關資料
Cohesion Coupling And Cohesion(http://c2.com/cgi/wiki?CouplingAndCohesion)
里氏代換原則
里氏代換原則（LSP）完全是關于對象的預期行為：
程序中的對象應該可以替換為其子類型的實例，而不會改變該程序的正確性。
相關資源
Liskov substitution principle(http://en.wikipedia.org/wiki/Liskov_substitution_principle) Liskov Substitution Principle(http://www.blackwasp.co.uk/lsp.aspx)
開放/封閉原則
軟件實體（例如類）應對擴展是開放的，但對修改是封閉的。也就是說，這樣的實體可以允許在不改變其源代碼的情況下修改其行為。
為什么
通過最小化對現(xiàn)有代碼的修改來提高可維護性和穩(wěn)定性
怎么做
編寫可以擴展的類（而不是可以修改的類） 只暴露需要更換的活動部分，隱藏其他所有部分。
相關資源
Open Closed Principle(http://en.wikipedia.org/wiki/Open/closed_principle) The Open Closed Principle(https://8thlight.com/blog/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html)
單一職責原則
一個類不應該有多個修改的原因。
長話版：每個類都應該有一個單獨的職責，并且該職責應該完全由該類封裝。職責可以定義為修改的原因，一次類或模塊應該有且僅有一個修改的原因。
為什么
可維護性：僅有一個模塊或類中需要修改。
怎么做
使用 科里定律(https://mouse0w0.github.io/2018/10/04/Programming-Principles/#科里定律).
相關資料
Single responsibility principle(http://en.wikipedia.org/wiki/Single_responsibility_principle)
隱藏實現(xiàn)細節(jié)
軟件模塊通過提供接口來隱藏信息（即實現(xiàn)細節(jié)），而不泄露任何不必要的信息。
為什么
當實現(xiàn)更改時，客戶端使用的接口不必更改。
怎么做
最小化類和成員的可訪問性。 不要公開成員數(shù)據(jù)。 避免將私有實現(xiàn)細節(jié)放入類的接口中。 減少耦合以隱藏更多實現(xiàn)細節(jié)。
相關資料
Information hiding(http://en.wikipedia.org/wiki/Information_hiding)
科里定律
科里定律是關于為任何特定代碼選擇一個明確定義的目標：僅做一件事。
Curly’s Law: Do One Thing(http://blog.codinghorror.com/curlys-law-do-one-thing/) The Rule of One or Curly’s Law(http://fortyplustwo.com/2008/09/06/the-rule-of-one-or-curlys-law/)
封裝經(jīng)常修改的代碼
一個好的設計可以辨別出最有可能改變的熱點，并將它們封裝在API之后。當預期的修改發(fā)生時，修改會保持在局部。
為什么
在發(fā)生更改時，最小化所需的修改。
怎么做
封裝API背后不同的概念。 將可能不同的概念分到各自的模塊。
相關資料
Encapsulate the Concept that Varies(http://principles-wiki.net/principles:encapsulate_the_concept_that_varies) Encapsulate What Varies(http://blogs.msdn.com/b/steverowe/archive/2007/12/26/encapsulate-what-varies.aspx) Information Hiding(https://en.wikipedia.org/wiki/Information_hiding)
接口隔離原則
將臃腫的接口減少到多個更小更具體的客戶端特定接口中。接口應該比實現(xiàn)它的代碼更依賴于調(diào)用它的代碼。
為什么
如果類實現(xiàn)了不需要的方法，則調(diào)用方需要了解該類的方法實現(xiàn)。例如，如果一個類實現(xiàn)了一個方法，但只是簡單的拋出異常，那么調(diào)用方將需要知道實際上不應該調(diào)用這個方法。
怎么做
避免臃腫的接口。類不應該實現(xiàn)任何違反單一職責原則(https://mouse0w0.github.io/2018/10/04/Programming-Principles/#單一職責原則)的方法。
相關資料
Interface segregation principle(https://en.wikipedia.org/wiki/Interface_segregation_principle)
童子軍軍規(guī)
美國童子軍有一條簡單的軍規(guī)，我們可以使用到我們的職業(yè)中：“離開營地時比你到達時更干凈”。根據(jù)童子軍軍規(guī)，我們應該至終保持代碼比我們看到時更干凈。
為什么
當對現(xiàn)有代碼庫進行更改時，代碼質量往往會降低，從而積累技術債務。根據(jù)童子軍軍規(guī)，我們應該注意每一個提交（Commit）的質量。無論規(guī)模有多小，技術債務都會受到不斷重構的抵制。
怎么做
每次提交都要確保它不會降低代碼庫的質量。 任何時候，如果有人看到一些代碼不夠清楚，他們就應該抓住機會在那里修復它。
相關資料
Opportunistic Refactoring(http://martinfowler.com/bliki/OpportunisticRefactoring.html)
命令查詢分離
命令查詢分離原則規(guī)定，每個方法都應該是執(zhí)行操作的命令，或者是向調(diào)用者返回數(shù)據(jù)但不能同時做兩件事的查詢。提問不應該改變答案。
利用這個原則，程序員可以更加自信地進行編碼。查詢方法可以在任何地方以任何順序使用，因為它們不會改變狀態(tài)。而使用命令，你必須更加小心。
為什么
通過將方法清晰地分為查詢和命令，程序員可以在不了解每個方法的實現(xiàn)細節(jié)的情況下，更加自信地編碼。
怎么做
將每個方法實現(xiàn)為查詢或命令。 對方法名使用命名約定，該方法名表示該方法是查詢還是命令。
相關資料
Command Query Separation in Wikipedia(https://en.wikipedia.org/wiki/Command–query_separation) Command Query Separation by Martin Fowler(http://martinfowler.com/bliki/CommandQuerySeparation.html)
作者 |?Mouse
最近熬夜給大家準備了515套Java代碼，有一些是業(yè)務類的小項目，比如Java博客項目，也有腳手架、也有平時用一些的工具類、21套小程序代碼，也有一些游戲類的項目。
掃以下二維碼并回復“828”即可獲取
或者在本公眾號對話框回復【828】馬上獲取
