設計模式之美學習（一）：設計模式對編程工做者是很重要的，它的做用不言而喻。

繼數據結構與算法之美后，王爭老師的專欄又開始更新了，此次是《設計模式之美》，但願學習以後會對本身有所提高。在此記錄下本身的學習筆記，但願對本身或者看到的讀者都有所裨益。

爲何每一個程序員都要儘早地學習並掌握設計模式相關知識？

1. 應對面試中的設計模式相關問題

學習設計模式和算法同樣，最功利、最直接的目的，可能就是應對面試了。

無論你是前端工程師、後端工程師，仍是全棧工程師，在求職面試中，設計模式問題是被問得頻率比較高的一類問題。特別是一些像 BAT、TMD 這樣的大公司，比較重視候選人的基本功，常常會拿算法、設計模式之類的問題來考察候選人。

2. 告別寫被人吐槽的爛代碼

咱們常常說，Talk is cheap，show me the code。實際上，代碼能力是一個程序員最基礎的能力，是基本功，是展現一個程序員基礎素養的最直接的衡量標準。你寫的代碼，實際上就是你名片。

3. 提升複雜代碼的設計和開發能力

大部分工程師比較熟悉的都是編程語言、工具、框架這些東西，由於天天的工做就是在框架里根據業務需求，填充代碼。實際上，這樣的工做並不須要你具有很強的代碼設計能力，只要單純地能理解業務，翻譯成代碼就能夠了。

可是，有一天，leader 讓開發一個跟業務無關的比較通用的功能模塊，面對這樣稍微複雜的代碼設計和開發，就發現會有點力不從心，不知從何下手了。由於只是完成功能、代碼能用，可能並不複雜，可是要想寫出易擴展、易用、易維護的代碼，並不容易。

如何分層、分模塊？應該怎麼劃分類？每一個類應該具備哪些屬性、方法？怎麼設計類之間的交互？該用繼承仍是組合？該使用接口仍是抽象類？怎樣作到解耦、高內聚低耦合？該用單例模式仍是靜態方法？用工廠模式建立對象仍是直接 new 出來？如何避免引入設計模式提升擴展性的同時帶來的下降可讀性問題？……各類問題，一會兒擠到面前。

4. 讓讀源碼、學框架事半功倍

對於一個有追求的程序員來講，對技術的積累，既要有廣度，也要有深度。不少技術人早早就意識到了這一點，因此在學習框架、中間件的時候，都會抽空去研究研究原理，讀一讀源碼，但願能在深度上有所積累，而不僅是略知皮毛，會用而已。

有些人看源碼的時候，常常會遇到看不懂、看不下去的問題。不知道你有沒有遇到過這種狀況？實際上，這個問題的緣由很簡單，那就是你積累的基本功還不夠，你的能力還不足以看懂這些代碼。

5. 爲你的職場發展作鋪墊

普通的、低級別的開發工程師，只須要把框架、開發工具、編程語言用熟練，再作幾個項目練練手，基本上就能應付平時的開發工做了。可是，若是你不想一生作一個低級的碼農，想成長爲技術專家、大牛、技術 leader，但願在職場有更高的成就、更好的發展，那就要重視基本功的訓練、基礎知識的積累。

你去看大牛寫的代碼，或者優秀的開源項目，代碼寫得都很是的優美，質量都很高。若是你只是框架用得很溜，架構聊得頭頭是道，但寫出來的代碼很爛，讓人一眼就能看出不少不合理的、能夠改進的地方，那你永遠都成不了別人心目中的「技術大牛」。

總結

總結一下的話，主要有這樣五點：應對面試中的設計模式相關問題；告別寫被人吐槽的爛代碼；提升複雜代碼的設計和開發能力；讓讀源碼、學框架事半功倍；爲你的職場發展作鋪墊。

投資要趁早，這樣咱們才能儘早享受複利。一樣，有些能力，要早點鍛鍊；有些東西，要早點知道；有些書，要早點讀。這樣在你後面的生活、工做、學習中，才能一直都發揮做用。不要等到好多年後，看到了，才恍然大悟，後悔沒有早點去學、去看。

設計模式做爲一門與編碼、開發有着直接關係的基礎知識，是你如今就要開始學習的。早點去學習，之後的項目就均可以拿來鍛鍊，每寫一行代碼都是對內功的利用和加深，是能夠受益一整個職業生涯的事情。

從哪些維度評判代碼質量的好壞？如何具有寫出高質量代碼的能力？

對於程序員來講，辨別代碼寫得「好」仍是「爛」，是一個很是重要的能力。這也是咱們寫出好代碼的前提。畢竟，若是咱們連什麼是好代碼、什麼是爛代碼，都分辨不清，又談何寫出好代碼呢？

如何評價代碼質量的高低？

下面是描述代碼質量的全部經常使用詞彙：

靈活性（flexibility）、可擴展性（extensibility）、可維護性（maintainability）、可讀性（readability）、可理解性（understandability）、易修改性（changeability）、可複用（reusability）、可測試性（testability）、模塊化（modularity）、高內聚低耦合（high cohesion loose coupling）、高效（high effciency）、高性能（high performance）、安全性（security）、兼容性（compatibility）、易用性（usability）、整潔（clean）、清晰（clarity）、簡單（simple）、直接（straightforward）、少便是多（less code is more）、文檔詳盡（well-documented）、分層清晰（well-layered）、正確性（correctness、bug free）、健壯性（robustness）、魯棒性（robustness）、可用性（reliability）、可伸縮性（scalability）、穩定性（stability）、優雅（elegant）、好（good）、壞（bad）……

實際上，咱們很難經過其中的某個或者某幾個詞彙來全面地評價代碼質量。由於這些詞彙都是從不一樣維度來講的。這就比如，對於一我的的評價，咱們須要綜合各個方面來給出，好比性格、相貌、能力、財富等等。代碼質量高低也是一個綜合各類因素獲得的結論。咱們並不能經過單一的維度去評價一段代碼寫的好壞。好比，即便一段代碼的可擴展性很好，但可讀性不好，那咱們也不能說這段代碼質量高。

除此以外，不一樣的評價維度也並非徹底獨立的，有些是具備包含關係、重疊關係或者能夠互相影響的。好比，代碼的可讀性好、可擴展性好，就意味着代碼的可維護性好。不過，咱們真的能夠客觀地量化一段代碼質量的高低嗎？答案是否認的。對一段代碼的質量評價，經常有很強的主觀性。

正是由於代碼質量評價的主觀性，使得這種主觀評價的準確度，跟工程師自身經驗有極大的關係。越是有經驗的工程師，給出的評價也就越準確。因此，這也致使若是沒有人指導的話，本身一我的悶頭寫代碼，即使寫再多的代碼，代碼能力也可能一直沒有太大提升。

最經常使用的評價標準有哪幾個？

其中幾個最經常使用的、最重要的評價標準，來詳細講解，其中就包括：可維護性、可讀性、可擴展性、靈活性、簡潔性（簡單、複雜）、可複用性、可測試性。

1. 可維護性（maintainability）

落實到編碼開發，所謂的「維護」無外乎就是修改 bug、修改老的代碼、添加新的代碼之類的工做。所謂「代碼易維護」就是指，在不破壞原有代碼設計、不引入新的 bug 的狀況下，可以快速地修改或者添加代碼。所謂「代碼不易維護」就是指，修改或者添加代碼須要冒着極大的引入新 bug 的風險，而且須要花費很長的時間才能完成。

維護、易維護、不易維護這三個概念不難理解。不過，對於實際的軟件開發來講，更重要的是搞清楚，如何來判斷代碼可維護性的好壞。從正面去分析一個代碼是否易維護稍微有點難度。不過，咱們能夠從側面上給出一個比較主觀但又比較準確的感覺。若是 bug 容易修復，修改、添加功能可以輕鬆完成，那咱們就能夠主觀地認爲代碼對咱們來講易維護。相反，若是修改一個 bug，修改、添加一個功能，須要花費很長的時間，那咱們就能夠主觀地認爲代碼對咱們來講不易維護。

2. 可讀性（readability）

軟件設計大師 Martin Fowler 曾經說過：Any fool can write code that a computer can understand. Good programmers write code that humans can understand.翻譯成中文就是：「任何傻瓜都會編寫計算機能理解的代碼。好的程序員可以編寫人可以理解的代碼。」

代碼的可讀性應該是評價代碼質量最重要的指標之一。咱們在編寫代碼的時候，時刻要考慮到代碼是否易讀、易理解。除此以外，代碼的可讀性在很是大程度上會影響代碼的可維護性。畢竟，無論是修改 bug，仍是修改添加功能代碼，咱們首先要作的事情就是讀懂代碼。代碼讀不大懂，就頗有可能由於考慮不周全，而引入新的 bug。

既然可讀性如此重要，那咱們又該如何評價一段代碼的可讀性呢？

實際上，code review 是一個很好的測驗代碼可讀性的手段。若是你的同事能夠輕鬆地讀懂你寫的代碼，那說明你的代碼可讀性很好；若是同事在讀你的代碼時，有不少疑問，那就說明你的代碼可讀性有待提升了。

3. 可擴展性（extensibilty）

可擴展性也是一個評價代碼質量很是重要的標準。它表示咱們的代碼應對將來需求變化的能力。跟可讀性同樣，代碼是否易擴展也很大程度上決定代碼是否易維護。那到底什麼是代碼的可擴展性呢？

代碼的可擴展性表示，咱們在不修改或少許修改原有代碼的狀況下，經過擴展的方式添加新的功能代碼。說直白點就是，代碼預留了一些功能擴展點，你能夠把新功能代碼，直接插到擴展點上，而不須要由於要添加一個功能而大動干戈，改動大量的原始代碼。

4. 靈活性（flexibility）

靈活性是一個挺抽象的評價標準，要給靈活性下個定義也是挺難的。不過，咱們能夠想一下，什麼狀況下咱們纔會說代碼寫得好靈活呢？我這裏羅列了幾個場景，但願能引起你本身對什麼是靈活性的思考。

• 當咱們添加一個新的功能代碼的時候，原有的代碼已經預留好了擴展點，咱們不須要修改原有的代碼，只要在擴展點上添加新的代碼便可。這個時候，咱們除了能夠說代碼易擴展，還能夠說代碼寫得好靈活。
• 當咱們要實現一個功能的時候，發現原有代碼中，已經抽象出了不少底層能夠複用的模塊、類等代碼，咱們能夠拿來直接使用。這個時候，咱們除了能夠說代碼易複用以外，還能夠說代碼寫得好靈活。
• 當咱們使用某組接口的時候，若是這組接口能夠應對各類使用場景，知足各類不一樣的需求，咱們除了能夠說接口易用以外，還能夠說這個接口設計得好靈活或者代碼寫得好靈活。

從剛剛舉的場景來看，若是一段代碼易擴展、易複用或者易用，咱們均可以稱這段代碼寫得比較靈活。因此，靈活這個詞的含義很是寬泛，不少場景下均可以使用。

5. 簡潔性（simplity）

有一條很是著名的設計原則，你必定聽過，那就是 KISS 原則：Keep It Simple，Stupid。這個原則說的意思就是，儘可能保持代碼簡單。代碼簡單、邏輯清晰，也就意味着易讀、易維護。咱們在編寫代碼的時候，每每也會把簡單、清晰放到首位。

不過，不少編程經驗不足的程序員會以爲，簡單的代碼沒有技術含量，喜歡在項目中引入一些複雜的設計模式，以爲這樣才能體現本身的技術水平。實際上，思從深而行從簡，真正的高手能雲淡風輕地用最簡單的方法解決最複雜的問題。這也是一個編程老手跟編程新手的本質區別之一。

6. 可複用性（reusability）

代碼的可複用性能夠簡單地理解爲，儘可能減小重複代碼的編寫，複用已有的代碼。實際上，代碼可複用性跟 DRY（Don’t Repeat Yourself）這條設計原則的關係挺緊密的.

7. 可測試性（testability）

相對於前面六個評價標準，代碼的可測試性是一個相對較少被說起，但又很是重要的代碼質量評價標準。代碼可測試性的好壞，能從側面上很是準確地反應代碼質量的好壞。代碼的可測試性差，比較難寫單元測試，那基本上就能說明代碼設計得有問題。

如何才能寫出高質量的代碼？

問如何寫出高質量的代碼，也就等同於在問，如何寫出易維護、易讀、易擴展、靈活、簡潔、可複用、可測試的代碼。

要寫出知足這些評價標準的高質量代碼，咱們須要掌握一些更加細化、更加能落地的編程方法論，包括面向對象設計思想、設計原則、設計模式、編碼規範、重構技巧等。而全部這些編程方法論的最終目的都是爲了編寫出高質量的代碼。

總結

1. 如何評價代碼質量的高低？

代碼質量的評價有很強的主觀性，描述代碼質量的詞彙也有不少，好比可讀性、可維護性、靈活、優雅、簡潔等，這些詞彙是從不一樣的維度去評價代碼質量的。它們之間有互相做用，並非獨立的，好比，代碼的可讀性好、可擴展性好就意味着代碼的可維護性好。代碼質量高低是一個綜合各類因素獲得的結論。咱們並不能經過單一的維度去評價一段代碼的好壞。

2. 最經常使用的評價標準有哪幾個？

最經常使用到幾個評判代碼質量的標準是：可維護性、可讀性、可擴展性、靈活性、簡潔性、可複用性、可測試性。其中，可維護性、可讀性、可擴展性又是提到最多的、最重要的三個評價標準。

3. 如何才能寫出高質量的代碼？

要寫出高質量代碼，咱們就須要掌握一些更加細化、更加能落地的編程方法論，這就包含面向對象設計思想、設計原則、設計模式、編碼規範、重構技巧等等。

面向對象、設計原則、設計模式、編程規範、重構，這五者有何關係？

面向對象

主流的編程範式或者是編程風格有三種，它們分別是面向過程、面向對象和函數式編程。面向對象這種編程風格又是這其中最主流的。如今比較流行的編程語言大部分都是面向對象編程語言。大部分項目也都是基於面向對象編程風格開發的。面向對象編程由於其具備豐富的特性（封裝、抽象、繼承、多態），能夠實現不少複雜的設計思路，是不少設計原則、設計模式編碼實現的基礎。

須要掌握的7大知識點：

• 面向對象的四大特性：封裝、抽象、繼承、多態
• 面向對象編程與面向過程編程的區別和聯繫
• 面向對象分析、面向對象設計、面向對象編程
• 接口和抽象類的區別以及各自的應用場景
• 基於接口而非實現編程的設計思想
• 多用組合少用繼承的設計思想
• 面向過程的貧血模型和麪向對象的充血模型

設計原則

設計原則是指導咱們代碼設計的一些經驗總結。設計原則這塊兒的知識有一個很是大的特色，那就是這些原則聽起來都比較抽象，定義描述都比較模糊，不一樣的人會有不一樣的解讀。因此，若是單純地去記憶定義，對於編程、設計能力的提升，意義並不大。對於每一種設計原則，咱們須要掌握它的設計初衷，能解決哪些編程問題，有哪些應用場景。只有這樣，咱們才能在項目中靈活恰當地應用這些原則。

須要掌握的經常使用設計原則：

• SOLID 原則 -SRP 單一職責原則
• SOLID 原則 -OCP 開閉原則
• SOLID 原則 -LSP 裏式替換原則
• SOLID 原則 -ISP 接口隔離原則
• SOLID 原則 -DIP 依賴倒置原則
• DRY 原則、KISS 原則、YAGNI 原則、LOD 法則

設計模式

設計模式是針對軟件開發中常常遇到的一些設計問題，總結出來的一套解決方案或者設計思路。大部分設計模式要解決的都是代碼的可擴展性問題。設計模式相對於設計原則來講，沒有那麼抽象，並且大部分都不難理解，代碼實現也並不複雜。這一塊的學習難點是瞭解它們都能解決哪些問題，掌握典型的應用場景，而且懂得不過分應用。

經典的設計模式能夠分爲三大類：建立型、結構型、行爲型。

1. 建立型

經常使用的有：單例模式、工廠模式（工廠方法和抽象工廠）、建造者模式。
不經常使用的有：原型模式。

2. 結構型

經常使用的有：代理模式、橋接模式、裝飾者模式、適配器模式。
不經常使用的有：門面模式、組合模式、享元模式。

3. 行爲型

經常使用的有：觀察者模式、模板模式、策略模式、職責鏈模式、迭代器模式、狀態模式。
不經常使用的有：訪問者模式、備忘錄模式、命令模式、解釋器模式、中介模式。

編程規範

編程規範主要解決的是代碼的可讀性問題。編碼規範相對於設計原則、設計模式，更加具體、更加偏重代碼細節。即使你可能對設計原則不熟悉、對設計模式不瞭解，但你最起碼要掌握基本的編碼規範，好比，如何給變量、類、函數命名，如何寫代碼註釋，函數不宜過長、參數不能過多等等。

代碼重構

在軟件開發中，只要軟件在不停地迭代，就沒有一勞永逸的設計。隨着需求的變化，代碼的不停堆砌，原有的設計一定會存在這樣那樣的問題。針對這些問題，咱們就須要進行代碼重構。重構是軟件開發中很是重要的一個環節。持續重構是保持代碼質量不降低的有效手段，能有效避免代碼腐化到無可救藥的地步。

而重構的工具就是咱們前面羅列的那些面向對象設計思想、設計原則、設計模式、編碼規範。

須要掌握的知識點有：

• 重構的目的（why）、對象（what）、時機（when）、方法（how）；
• 保證重構不出錯的技術手段：單元測試和代碼的可測試性；
• 兩種不一樣規模的重構：大重構（大規模高層次）和小重構（小規模低層次）。

五者之間的聯繫

• 面向對象編程由於其具備豐富的特性（封裝、抽象、繼承、多態），能夠實現不少複雜的設計思路，是不少設計原則、設計模式等編碼實現的基礎。
• 設計原則是指導咱們代碼設計的一些經驗總結，對於某些場景下，是否應該應用某種設計模式，具備指導意義。好比，「開閉原則」是不少設計模式（策略、模板等）的指導原則。
• 設計模式是針對軟件開發中常常遇到的一些設計問題，總結出來的一套解決方案或者設計思路。應用設計模式的主要目的是提升代碼的可擴展性。從抽象程度上來說，設計原則比設計模式更抽象。設計模式更加具體、更加可執行。
• 編程規範主要解決的是代碼的可讀性問題。編碼規範相對於設計原則、設計模式，更加具體、更加偏重代碼細節、更加能落地。持續的小重構依賴的理論基礎主要就是編程規範。
• 重構做爲保持代碼質量不降低的有效手段，利用的就是面向對象、設計原則、設計模式、編碼規範這些理論。

實際上，面向對象、設計原則、設計模式、編程規範、代碼重構，這五者都是保持或者提升代碼質量的方法論，本質上都是服務於編寫高質量代碼這一件事的。當咱們追本逐源，看清這個本質以後，不少事情怎麼作就清楚了，不少選擇怎麼選也清楚了。好比，在某個場景下，該不應用這個設計模式，那就看能不能提升代碼的可擴展性；要不要重構，那就看重代碼是否存在可讀、可維護問題等。

總結

歡迎小夥伴們和我一塊兒學習。

本文由博客一文多發平臺 OpenWrite 發佈！
更多內容請點擊個人博客 沐晨