設計模式專欄
1. 單一職責原則(SRP)
定義：就一個類而言，應該僅有一個引起它變化的原因。
從這句定義我們很難理解它的含義，通俗講就是我們不要讓一個類承擔過多的職責。如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到破壞。
比如我經常看到一些Android開發在Activity中寫Bean文件，網絡數據處理，如果有列表的話Adapter 也寫在Activity中，問他們爲什麼除了好找也沒啥理由了，把他們拆分到其他類豈不是更好找，如果Activity過於臃腫行數過多，顯然不是好事，如果我們要修改Bean文件，網絡處理和Adapter都需要上這個Activity來修改，就會導致引起這個Activity變化的原因太多，我們在版本維護時也會比較頭疼。也就嚴重違背了定義“就一個類而言，應該僅有一個引起它變化的原因”。
當然如果想爭論的話，這個模式是可以引起很多爭論的，但請記住一點，你寫代碼不只是爲了你也是爲了其他人。
2. 開放封閉原則(ASD)
定義：類、模塊、函數等等等應該是可以拓展的，但是不可修改。
開放封閉有兩個含義，一個是對於拓展是開放的，另一個是對於修改是封閉的。對於開發來說需求肯定是要變化的，但是新需求一來，我們就要把類重新改一遍這顯然是令人頭疼的，所以我們設計程序時面對需求的改變要儘可能的保證相對的穩定，儘量用新代碼實現拓展來修改需求，而不是通過修改原有的代碼來實現。
假設我們要實現一個列表，一開始只有查詢的功能，如果產品又要增加添加功能，過幾天又要增加刪除功能，大多數人的做法是寫個方法然後通過傳入不同的值來控制方法來實現不同的功能，但是如果又要新增功能我們還得修改我們的方法。用開發封閉原則解決就是增加一個抽象的功能類，讓增加和刪除和查詢的作爲這個抽象功能類的子類，這樣如果我們再添加功能，你會發現我們不需要修改原有的類，只需要添加一個功能類的子類實現功能類的方法就可以了。
3.里氏替換原則(LSP)
定義：所有引用基類（父類）的地方必須能透明地使用其子類的對象
里氏代換原則告訴我們，在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那麼它不一定能夠使用基類對象。
里氏代換原則是實現開閉原則的重要方式之一，由於使用基類對象的地方都可以使用子類對象，因此在程序中儘量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。
在使用里氏代換原則時需要注意如下幾個問題：
- 子類的所有方法必須在父類中聲明，或子類必須實現父類中聲明的所有方法。根據里氏代換原則，爲了保證系統的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。
- 我們在運用里氏代換原則時，儘量把父類設計爲抽象類或者接口，讓子類繼承父類或實現父接口，並實現在父類中聲明的方法，運行時，子類實例替換父類實例，我們可以很方便地擴展系統的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現。里氏代換原則是開閉原則的具體實現手段之一。
- Java語言中，在編譯階段，Java編譯器會檢查一個程序是否符合里氏代換原則，這是一個與實現無關的、純語法意義上的檢查，但Java編譯器的檢查是有侷限的。
4.依賴倒置原則(DIP)
定義：高層模塊不應該依賴低層模塊，兩個都應該依賴於抽象。抽象不應該依賴於細節，細節應該依賴於抽象。
在Java中，抽象就是指接口或者抽象類，兩者都是不能直接被實例化的；細節就是實現類，實現接口或者繼承抽象類而產生的就是細節，也就是可以加上一個關鍵字new產生的對象。高層模塊就是調用端，低層模塊就是具體實現類。
依賴倒置原則在Java中的表現就是：模塊間通過抽象發生，實現類之間不發生直接依賴關係，其依賴關係是通過接口或者抽象類產生的。如果類與類直接依賴細節，那麼就會直接耦合，那麼當修改時，就會同時修改依賴者代碼，這樣限制了可擴展性。
5.迪米特原則(LOD)
定義：一個軟件實體應當儘可能少地與其他實體發生相互作用。
也稱爲最少知識原則。如果一個系統符合迪米特法則，那麼當其中某一個模塊發生修改時，就會盡量少地影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特法則要求限制軟件實體之間通信的寬度和深度。迪米特法則可降低系統的耦合度，使類與類之間保持鬆散的耦合關係。
迪米特法則要求我們在設計系統時，應該儘量減少對象之間的交互，如果兩個對象之間不必彼此直接通信，那麼這兩個對象就不應當發生任何直接的相互作用，如果其中的一個對象需要調用另一個對象的某一個方法的話，可以通過第三者轉發這個調用。簡言之，就是通過引入一個合理的第三者來降低現有對象之間的耦合度。
在將迪米特法則運用到系統設計中時，要注意下面的幾點：在類的劃分上，應當儘量創建鬆耦合的類，類之間的耦合度越低，就越有利於複用，一個處在鬆耦合中的類一旦被修改，不會對關聯的類造成太大波及；在類的結構設計上，每一個類都應當儘量降低其成員變量和成員函數的訪問權限；在類的設計上，只要有可能，一個類型應當設計成不變類；在對其他類的引用上，一個對象對其他對象的引用應當降到最低。
6.接口隔離原則(ISP)
定義：一個類對另一個類的依賴應該建立在最小的接口上。
建立單一接口，不要建立龐大臃腫的接口，儘量細化接口，接口中的方法儘量少。也就是說，我們要爲各個類建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。
採用接口隔離原則對接口進行約束時，要注意以下幾點：
- 接口儘量小，但是要有限度。對接口進行細化可以提高程序設計靈活性，但是如果過小，則會造成接口數量過多，使設計複雜化。所以一定要適度。
- 爲依賴接口的類定製服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地爲一個模塊提供定製服務，才能建立最小的依賴關係。
- 提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。
這六個原則，可以使我們在應用的迭代維護中更加方便、輕鬆的應對，讓我們的軟件更加靈活。在後續的文章中我會給大家介紹其他的設計模式。
GoF提出的設計模式總共有23種，根據目的準則分類分爲三大類：
創建型模式，共五種：單例模式、工廠方法模式、抽象工廠模式、建造者模式、原型模式。
結構型模式，共七種：適配器模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行爲型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代器模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。