決戰設計模式01——設計模式導論

「學會享受寂寞，那會讓你學會思考自我。」
——加西亞·馬爾克斯

一、設計模式概念與歷史

設計模式（Design Pattern）是一套被反覆 反復使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是爲了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使程式碼編制 編製真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。

設計模式代表了最佳的實踐，通常被有經驗的物件導向的軟件開發人員所採用。設計模式是軟件開發人員在軟件開發過程中面臨的一般問題的解決方案。

1、設計模式歷史

「設計模式」這個術語最初並不是出現在軟體設計中，而是被用於建築領域的設計中。1977 年，美國著名建築大師、加利福尼亞大學伯克利分校環境結構中心主任克裡斯托夫·亞歷山大（Christopher Alexander）在他的著作《建築模式語言：城鎮、建築、構造（A Pattern Language: Towns Building Construction）中描述了一些常見的建築設計問題，並提出了 253 種關於對城鎮、鄰裡、住宅、花園和房間等進行設計的基本模式。1979 年他的另一部經典著作《建築的永恆之道》（The Timeless Way of Building）進一步強化了設計模式的思想，爲後來的建築設計指明瞭方向。1987 年，肯特·貝克（Kent Beck）和沃德·坎寧安（Ward Cunningham）首先將克裡斯托夫·亞歷山大的模式思想應用在 Smalltalk 中的圖形使用者介面的生成中，但沒有引起軟體界的關注。直到 1990 年，軟體工程界纔開始研討設計模式的話題，後來召開了多次關於設計模式的研討會。1995 年，艾瑞克·伽馬（ErichGamma）、理査德·海爾姆（Richard Helm）、拉爾夫·約翰森（Ralph Johnson）、約翰·威利斯迪斯（John Vlissides）等 4 位作者合作出版了《設計模式：可複用物件導向軟體的基礎》（Design Patterns: Elements of Reusable Object-Oriented Software）一書，在本教學中收錄了 23 個設計模式，這是設計模式領域裏程碑的事件，導致了軟體設計模式的突破。這 4 位作者在軟件開發領域裏也以他們的「四人組」（Gang of Four，GoF）匿名著稱。

[附]模式的經典定義：每個模式都描述了一個在我們的環境中不斷出現的問題，然後描述了該問題的解決方案的核心，通過這種方式，我們可以無數次地重用那些已有的解決方案，無需再重複相同的工作。即模式是在特定環境中解決問題的一種方案 。

2、 設計模式目的

其目的就是一方面教你如何利用真實可靠的設計來組織程式碼的模板。簡單地說，就是從前輩們在程式設計過程中總結、抽象出來的通用優秀經驗。

1.增加程式的靈活性、可重用性。
2.有助於程式設計的標準化和提高系統開發進度。

但是，不應該過於注重程式的「設計模式」。有時候，寫一個簡單的演算法，要比引入某種模式更容易。在多數情況下，程式程式碼應是簡單易懂，甚至清潔工也能看懂。不過呢在大專案或者框架中，沒有設計模式來組織程式碼，別人是不易理解的。

一個軟體設計模型也僅僅只是一個引導。它必須根據程式設計語言和你的應用程式的特點和要求而特別的設計。

3、 設計模式的使用

設計模式在軟件開發中的兩個主要用途。

->開發人員的共同平臺

設計模式提供了一個標準的術語系統，且具體到特定的情景。例如，單例設計模式意味着使用單個物件，這樣所有熟悉單例設計模式的開發人員都能使用單個物件，並且可以通過這種方式告訴對方，程式使用的是單例模式。

->最佳的實踐

設計模式已經經歷了很長一段時間的發展，它們提供了軟件開發過程中面臨的一般問題的最佳解決方案。學習這些模式有助於經驗不足的開發人員通過一種簡單快捷的方式來學習軟體設計。

4、設計模式的四個基本要素

設計模式使人們可以更加簡單方便地複用成功的設計和體系結構。將已證實的技術表述成設計模式也會使新系統開發者更加容易理解其設計思路。

所有的設計模式都有一些常用的特性：一個標識（a pattern name），一個問題陳述（a problem statement）和一個解決方案(a solution)，效果(consequences)。

模式名稱（pattern name）： 描述模式的問題、解決方案和效果。

一個設計模式的標識（模式名稱）是重要的，因爲它會讓其他的程式設計師不用進行太深入的學習就能立刻理解你的程式碼的目的（至少通過這個標識程式設計師會很熟悉這個模式）。沒有這個模式名，我們便無法與其他人交流設計思想及設計結果。

問題(problem) ：描述是用來說明這個模式的應用的領域。

描述了應該在何時使用模式。它解釋了設計問題和問題存在的前因後果，它可能描述了特定的設計問題，如怎樣用物件表示演算法等。也可能描述了導致不靈活設計的類或物件結構。有時候，問題部分會包括使用模式必須滿足的一系列先決條件。

解決方案(solution) ： 描述了這個模型的執行。

描述了設計的組成成分，它們之間的相互關係及各自的職責和共同作業方式。因爲模式就像一個模板，可應用於多種不同場合，所以解決方案並不描述一個特定而具體的設計或實現，而是提供設計問題的抽象描述和怎樣用一個具有一般意義的元素組合（類或物件組合）來解決這個問題。

效果(consequences)

描述了模式應用的效果及使用模式應權衡的問題。儘管我們描述設計決策時，並不總提到模式效果，但它們對於評價設計選擇和理解使用模式的代價及好處具有重要意義。軟體效果大多關注對時間和空間的衡量，它們也表述了語言和實現問題。因爲複用是物件導向設計的要素之一，所以模式效果包括它對系統的靈活性、擴充性或可移植性的影響，顯式地列出這些效果對理解和評價這些模式很有幫助。

一個好的設計模式的論述應該覆蓋使用這個模型的優點和缺點。

一個模式是解決特定問題的有效方法。一個設計模式不是一個庫（能在你的專案中直接包含和使用的程式碼庫）而是一個用來組織你的程式碼的模板（Java bean）。事實上，一個程式碼庫和一個設計模式在應用上是有很多不同的。

比如，你從店鋪裏面買的一件襯衫是一個程式碼庫，它的顏色，樣式和大小都由設計師和廠商決定，但它滿足了你的需求。 然而，如果店裏面沒有什麼衣服適合你，那你就能自己建立自己的襯衫（設計它的形狀，選擇布料，然後裁縫在一起）。但是如果你不是一個裁縫，你可能會發現自 己很容易的去找一個合適的模式然後按着這個模式去設計自己的襯衫。使用一個模型，你可以在更少的時間內得到一個熟練設計的襯衫。

回到討論軟體上來，一個數據提取層或者一個CMS（content management system）就是一個庫——它是先前設計好而且已經編碼好了的，如果它能準確的滿足你的需要那它就是一個好的選擇。但如果你正在讀這本書《設計模式》，可能你會發現 庫存的（原有的）解決方案並不是總是對你有效。至今你知道什麼是你所要的，而且你能夠實現它，你僅僅需要一個模型來引導你。

最後一個想法：就象一個裁縫模型，一個設計本身而言是沒有什麼用處的。畢竟，你不可能穿一個服裝模型——它僅僅是由很薄的紙拼湊起來的。類似的，一個軟體設計模型也僅僅只是一個引導。它必須根據程式設計語言和你的應用程式的特點和要求而特別的設計。

二、設計模式分類

1）根據其目的（模式是用來做什麼的）可分爲建立型(Creational)，結構型(Structural)和行爲型(Behavioral)三種：

• 建立型模式主要用於建立物件。
• 結構型模式主要用於處理類或物件的組合。
• 行爲型模式主要用於描述對類或物件怎樣互動和怎樣分配職責。

2）根據範圍，即模式主要是用於處理類之間關係還是處理物件之間的關係，可分爲類模式和物件模式兩種：

• 類模式： 處理類和子類之間的關係，這些關係通過繼承建立，在編譯時刻就被確定下來，是屬於靜態的。
• 物件模式：處理物件間的關係，這些關係在執行時刻變化，更具動態性。

1、建立型模式

這些設計模式提供了一種在建立物件的同時隱藏建立邏輯的方式，而不是使用 new 運算子直接範例化物件。這使得程式在判斷針對某個給定範例需要建立哪些物件時更加靈活。

類模式：工廠方法模式（Factory Pattern）
物件模式：
抽象工廠模式（Abstract Factory Pattern）
建造者模式（Builder Pattern）
原型模式（Prototype Pattern）
單例模式（Singleton Pattern）

2、結構型模式

這些設計模式關注類和物件的組合。繼承的概念被用來組合介面和定義組合物件獲得新功能的方式。

類模式：（類）適配器模式（Adapter Pattern）
物件模式：
（物件）適配器模式（Adapter Pattern）
橋接模式（Bridge Pattern）
組合模式（Composite Pattern）
裝飾器模式（Decorator Pattern）
外觀模式（Facade Pattern）
享元模式（Flyweight Pattern）
代理模式（Proxy Pattern）

3、行爲型模式

這些設計模式特別關注物件之間的通訊。

類模式：直譯器模式（Interpreter Pattern）
物件模式：
責任鏈模式（Chain of Responsibility Pattern）
命令模式（Command Pattern）
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
備忘錄模式（Memento Pattern）
觀察者模式（Observer Pattern）
狀態模式（State Pattern）
空物件模式（Null Object Pattern）
策略模式（Strategy Pattern）
模板模式（Template Pattern）
存取者模式存取者模式（Visitor Pattern）

三、基本設計模式的定義

Abstract Factory（抽象工廠模式）：提供一個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類。

Adapter（適配器模式）：將一個類的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。

Bridge（橋接模式）：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。

Builder（建造者模式）：將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。

Chain of Responsibility 職責鏈：爲解除請求的發送者和接收者之間耦合，而使多個物件都有機會處理這個請求。將這些物件連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個物件處理它。

Command（命令模式）：將一個請求封裝爲一個物件，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支援可取消的操作。

Composite 組合模式：將物件組合成樹形結構以表示「部分-整體」的層次結構。它使得客戶對單個物件和複合物件的使用具有一致性。

Decorator 裝飾器：動態地給一個物件新增一些額外的職責。就擴充套件功能而言， 它比生成子類方式更爲靈活。

Facade（外觀模式）：爲子系統中的一組介面提供一個一致的介面， Facade模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。

Factory Method 工廠方法：定義一個用於建立物件的介面，讓子類決定將哪一個類範例化。Factory Method使一個類的範例化延遲到其子類。

Flyweight（享元模式）：運用共用技術有效地支援大量細粒度的物件。

Interprter（Interprter模式）：給定一個語言, 定義它的文法的一種表示，並定義一個直譯器, 該直譯器使用該表示來解釋語言中的句子。

Iterator迭代器：提供一種方法順序存取一個聚合物件中各個元素, 而又不需暴露該物件的內部表示。

Mediator 中介者：用一箇中介物件來封裝一系列的物件互動。中介者使各物件不需要顯式地相互參照，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。

Memento（備忘錄模式）：在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到儲存的狀態。

Observer（觀察者模式）：定義物件間的一種一對多的依賴關係,以便當一個物件的狀態發生改變時,所有依賴於它的物件都得到通知並自動重新整理。

Prototype（原型模式）：用原型範例指定建立物件的種類，並且通過拷貝這個原型來建立新的物件。

Proxy（代理模式）：爲其他物件提供一個代理以控制對這個物件的存取。

Singleton（單例模式）：保證一個類僅有一個範例，並提供一個存取它的全域性存取點。

State（狀態）：允許一個物件在其內部狀態改變時改變它的行爲。物件看起來似乎修改了它所屬的類。

Strategy（策略模式）：定義一系列的演算法,把它們一個個封裝起來, 並且使它們可相互替換。本模式使得演算法的變化可獨立於使用它的客戶。

Template Method 模板方法：定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。

Visitor（存取者模式）：表示一個作用於某物件結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。

四、設計模式六大原則

1）[設計模式的核心原則] 開閉原則( Open - Closed Principle 縮寫:OCP):對擴充套件開放，對修改關閉。

一個系統對於擴充套件是開放的,對於修改是關閉的。一個好的系統是在不修改原始碼的情況下,可以擴充套件你的功能。而實現開閉原則的關鍵就是抽象化。

通過擴充套件已有軟件系統，可以提供新的行爲，以滿足對軟體的新的需求，使變化中的軟體有一定的適應性和靈活性。已有軟體模組，特別是最重要的抽象層模組不能再修改，這使變化中的軟件系統有一定的穩定性和延續性。

在"開-閉"原則中,不允許修改的是抽象的類或者介面,允許擴充套件的是具體的實現類,抽象類和介面在"開-閉"原則中扮演着極其重要的角色…即要預知可能變化的需求.又預見所有可能已知的擴充套件。所以在這裏"抽象化"是關鍵。

可變性的封閉原則:找到系統的可變因素,將它封裝起來。這是對"開-閉"原則最好的實現。不要把你的可變因素放在多個類中,或者散落在程式的各個角落。你應該將可變的因素,封套起來。並且切忌不要把所用的可變因素封套在一起。最好的解決辦法是,分塊封套你的可變因素，避免超大類,超長類,超長方法的出現。

將程式藝術化是我們的目標!

2） 裡氏代換原則(Liskov Substitution Principle):任何基礎類別可以出現的地方,子類也可以出現。

子類能夠必須能夠替換基礎類別能夠從出現的地方。子類也能在基礎類別 的基礎上新增行爲。這裏講的是基礎類別和子類的關係，只有這種關係存在時，裡氏代換原則才存在。正方形是長方形是理解裡氏代換原則的經典例子。

3） 依賴倒轉原則(Dependence Inversion Principle):要依賴抽象,而不要依賴具體的實現。

依賴倒置原則要求用戶端依賴於抽象耦合。原則表述：

（1）抽象不應當依賴於細節；細節應當依賴於抽象；
（2）要針對介面程式設計，不針對實現程式設計。

如果說開閉原則是目標,依賴倒轉原則是到達"開閉"原則的手段…如果要達到最好的"開閉"原則,就要儘量的遵守依賴倒轉原則。可以說依賴倒轉原則是對"抽象化"的最好規範。我個人感覺,依賴倒轉原則也是裡氏代換原則的補充。理解了裡氏代換原則,再來理解依賴倒轉原則應該是很容易的。

4）合成/聚合複用原則（CARP）:要儘量使用合成/聚合原則,而不是繼承關係達到軟體複用的目的。

合成/聚合複用原則（Composite/Aggregate ReusePrinciple或CARP）經常又叫做合成複用原則（Composite ReusePrinciple或CRP），就是在一個新的物件裏面使用一些已有的物件，使之成爲新物件的一部分；新物件通過向這些物件的委派達到複用已有功能的目的。簡而言之，要儘量使用合成/聚合，儘量不要使用繼承。

要儘量使用合成/聚合原則,而不是繼承關係達到軟體複用的目的。此原則和裡氏代換原則氏相輔相成的,兩者都是具體實現"開-閉"原則的規範。違反這一原則:就無法實現"開-閉"原則。先來看看什麼是合成,什麼是聚合。

什麼是合成?

合成:是指一個整體對依託他而存在的關係,例如:一個人對他的房子和傢俱,其中他的房子和傢俱是不能被共用的,因爲那些東西都是他自己的。並且人沒了,這個也關係就沒了。這個例子就好像,烏雞百鳳丸這個產品,它是有烏雞和上等藥材合成而來的一樣。也比如網絡遊戲中的武器裝備合成一樣,多種東西合併爲一種超強的東西一樣。

什麼是聚合?

聚合:聚合是比合成關係的一種更強的依賴關係,聚合是一個整體對個體的部分,例如,一個奔馳S360汽車,對奔馳S360引擎,奔馳S360輪胎的關係。這些關係就是帶有聚合性質的。因爲奔馳S360引擎和奔馳S360輪胎他們只能被奔馳S360汽車所用,離開了奔馳S360汽車,它們就失去了存在的意義。在我們的設計中,這樣的關係不應該頻繁出現。這樣會增大設計的耦合度。

明白了合成和聚合關係,再來理解合成/聚合原則應該就清楚了。要避免在系統設計中出現,一個類的繼承層次超過3次。如果這樣的話,可以考慮重構你的程式碼,或者重新設計結構。當然最好的辦法就是考慮使用合成/聚合原則。

5）迪米特法則（Law of Demeter或簡寫LoD）:系統中的類,儘量不要與其他類互相作用,減少類之間的耦合度。

迪米特法則又叫最少知識原則（Least Knowledge Principle或簡寫爲LKP），也就是說，一個物件應當對其它物件有儘可能少的瞭解。

其它表述：只與你直接的朋友們通訊，不要跟"陌生人"說話。一個類應該對自己需要耦合或呼叫的類知道得最少，你（被耦合或呼叫的類）的內部是如何複雜都和我沒關係，那是你的事情，我就知道你提供的public方法，我就呼叫這麼多，其他的一概不關心。

迪米特法則與設計模式Facade模式、Mediator模式相通。

系統中的類,儘量不要與其他類互相作用,減少類之間的耦合度,因爲在你的系統中,擴充套件的時候,你可能需要修改這些類,而類與類之間的關係,決定了修改的複雜度,相互作用越多,則修改難度就越大,反之,如果相互作用的越小,則修改起來的難度就越小。例如A類依賴B類,則B類依賴C類,當你在修改A類的時候,你要考慮B類是否會受到影響,而B類的影響是否又會影響到C類。如果此時C類再依賴D類的話……我想這樣的修改有的受了。

6）介面隔離法則（Interface Segregation Principle）:

使用多個專門的介面比使用單一的總介面總要好。換而言之，從一個客戶類的角度來講：一個類對另外一個類的依賴性應當是建立在最小介面上的。

過於臃腫的介面是對介面的污染。不應該強迫客戶依賴於它們不用的方法。

迪米特法則是目的,而介面隔離法則是對迪米特法則的規範。爲了做到儘可能小的耦合性,我們需要使用介面來規範類,用介面來約束類。要達到迪米特法則的要求,最好就是實現介面隔離法則,實現介面隔離法則,你也就滿足了迪米特法則。

五、總結

設計模式是從許多優秀的軟件系統中總結出的成功的、能夠實現可維護性複用的設計方案，使用這些方案將避免我們做一些重複性的工作，而且可以設計出高品質的軟件系統。

設計模式的主要優點如下：

1）設計模式融合了衆多專家的經驗，並以一種標準的形式供廣大開發人員所用，它提供了一套通用的設計詞彙和一種通用的語言以方便開發人員之間溝通和交流，使得設計方案更加通俗易懂。對於使用不同程式語言的開發和設計人員可以通過設計模式來交流系統設計方案，每一個模式都對應一個標準的解決方案，設計模式可以降低開發人員理解系統的複雜度。

2）設計模式使人們可以更加簡單方便地複用成功的設計和體系結構，將已證實的技術表述成設計模式也會使新系統開發者更加容易理解其設計思路。設計模式使得重用成功的設計更加容易，並避免那些導致不可重用的設計方案。

3）設計模式使得設計方案更加靈活，且易於修改。

4）設計模式的使用將提高軟件系統的開發效率和軟體品質，且在一定程度上節約設計成本。

5）設計模式有助於初學者更深入地理解物件導向思想，一方面可以幫助初學者更加方便地閱讀和學習現有類庫與其他系統中的原始碼，另一方面還可以提高軟體的設計水平和程式碼品質。

設計模式不是學出來的，是用出來的。爲了學習設計模式而學習，效果可能不是很好。一般框架都會使用設計模式。如PHP 的ZF用來很多設計模式，框架裏面的類名或者目錄名，都以某種設計模式的名稱命名，這樣大家一看到這個類名或者檔名，就知道它的程式碼組織結構了。如果精通了語言,剩下的編碼自然是很簡單,隨着編碼經驗積累,對設計模式和原則的理解也就越透徹，其過程就是山窮水復疑無路，而結果柳暗花明又一村。

熟練模式後，切勿因模式而去模式。

像著名數學家華羅庚談到讀書的三個境界所說，「讀書是由薄到厚，再由厚到薄的過程」。

[附]Christopher Diggins 《優秀程式設計的18大原則》

1.避免重複原則(DRY - Don’t repeat yourself)

程式設計的最基本原則是避免重複。在程式程式碼中總會有很多結構體，如回圈、函數、類等等。一旦你重複某個語句或概念，就會很容易形成一個抽象體。

2.抽象原則(Abstraction Principle )

與DRY原則相關。要記住，程式程式碼中每一個重要的功能，只能出現在原始碼的一個位置。

3.簡單原則(Keep It Simple and Stupid )

簡單是軟體設計的目標，簡單的程式碼佔用時間少，漏洞少，並且易於修改。

4.避免建立你不要的程式碼 Avoid Creating a YAGNI (You aren’t going to need it)

除非你需要它，否則別建立新功能。

5.儘可能做可執行的最簡單的事(Do the simplest thing that could possibly work)

儘可能做可執行的最簡單的事。在程式設計中，一定要保持簡單原則。作爲一名程式設計師不斷的反思「如何在工作中做到簡化呢?」這將有助於在設計中保持簡單的路徑。

6.別讓我思考(Don’t make me think )

這是Steve Krug一本書的標題，同時也和程式設計有關。所編寫的程式碼一定要易於讀易於理解，這樣別人纔會欣賞，也能夠給你提出合理化的建議。相反，若是繁雜難解的程式，其他人總是會避而遠之的。

7.開閉原則(Open/Closed Principle)

你所編寫的軟體實體(類、模組、函數等)最好是開源的，這樣別人可以拓展開發。不過，對於你的程式碼，得限定別人不得修改。換句話說，別人可以基於你的程式碼進行拓展編寫，但卻不能修改你的程式碼。

8.程式碼維護(Write Code for the Maintainer)

一個優秀的程式碼，應當使本人或是他人在將來都能夠對它繼續編寫或維護。程式碼維護時，或許本人會比較容易，但對他人卻比較麻煩。因此你寫的程式碼要儘可能保證他人能夠容易維護。用書中原話說「如果一個維護者不再繼續維護你的程式碼，很可能他就有想殺了你的衝動。」

9.最小驚訝原則(Principle of least astonishment)

最小驚訝原則通常是在用戶介面方面參照，但同樣適用於編寫的程式碼。程式碼應該儘可能減少讓讀者驚喜。也就是說，你編寫的程式碼只需按照專案的要求來編寫。其他華麗的功能就不必了，以免弄巧成拙。

10.單一責任原則(Single Responsibility Principle)

某個程式碼的功能，應該保證只有單一的明確的執行任務。

11.低耦合原則(Minimize Coupling)

程式碼的任何一個部分應該減少對其他區域程式碼的依賴關係。儘量不要使用共用參數。低耦合往往是完美結構系統和優秀設計的標誌。

12.最大限度凝聚原則(Maximize Cohesion)

相似的功能程式碼應儘量放在一個部分。

13.隱藏實現細節(Hide Implementation Details)

隱藏實現細節原則，當其他功能部分發生變化時，能夠儘可能降低對其他元件的影響。

14.迪米特法則又叫作最少知識原則(Law of Demeter)

該程式碼只和與其有直接關係的部分連線。(比如：該部分繼承的類，包含的物件，參數傳遞的物件等)。

15.避免過早優化(Avoid Premature Optimization)

除非你的程式碼執行的比你想像中的要慢，否則別去優化。假如你真的想優化，就必須先想好如何用數據證明，它的速度變快了。

「過早的優化是一切罪惡的根源」——Donald.E.Knuth

16.程式碼重用原則(Code Reuse is Good)

重用程式碼能提高程式碼的可讀性，縮短開發時間。

17.關注點分離(Separation of Concerns)

不同領域的功能，應該由不同的程式碼和最小重迭的模組組成。

18.擁抱改變(Embrace Change)

這是Kent Beck一本書的標題，同時也被認爲是極限程式設計和敏捷方法的宗旨。

許多其他原則都是基於這個概唸的，即你應該積極面對變化。事實上，一些較老的程式設計原則如最小化耦合原則都是爲了使程式碼能夠容易變化。無論你是否是個極限程式設計者，基於這個原則去編寫程式碼會讓你的工作變得更有意義。

歡迎關注我的微信公衆號，獲取持續推播與資料分享！

參考資料
[1]設計模式簡介
https://www.runoob.com/design-pattern/design-pattern-intro.html
[2]設計模式概論
https://blog.csdn.net/hguisu/article/details/7496819
[3]優秀程式設計的18大原則 Christopher Diggins
https://www.artima.com/weblogs/viewpost.jsp?thread=331531
[4] 百度百科——軟體設計模式
[5] 《計算機程式設計藝術》Donald.E.Knuth國防工業出版社
[6] 《Head First設計模式》Freeman 中國電力出版社

本文由公衆號工程實戰派整理編寫。
本文遵照Creative-Commons 4.0協定發表。