一、設計模式的分類
總體來說設計模式分為三大類：
（1）創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
（2）結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
（3）行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
其實還有兩類：並發型模式和線程池模式。用一個圖片來整體描述一下：
二、設計模式的六大原則
1、開閉原則（Open Close Principle）
開閉原則就是說對擴展開放，對修改關閉。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，我們需要使用接口和抽象類，后面的具體設計中我們會提到這點。
2、里氏代換原則（Liskov Substitution Principle）
里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規范。—— From Baidu 百科
3、依賴倒轉原則（Dependence Inversion Principle）
這個是開閉原則的基礎，具體內容：真對接口編程，依賴於抽象而不依賴於具體。
4、接口隔離原則（Interface Segregation Principle）
這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟件的設計思想，從大型軟件架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。
5、迪米特法則（最少知道原則）（Demeter Principle）
為什么叫最少知道原則，就是說：一個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立。
6、合成復用原則（Composite Reuse Principle）
原則是盡量使用合成/聚合的方式，而不是使用繼承。
三、Java的23中設計模式
從這一塊開始，我們詳細介紹Java中23種設計模式的概念，應用場景等情況，並結合他們的特點及設計模式的原則進行分析。
1、工廠方法模式（Factory Method）
工廠方法模式分為以下三種：
（1）、普通工廠模式
就是建立一個工廠類，對實現了同一接口的一些類進行實例的創建。首先看下關系圖：
舉例如下：（我們舉一個發送郵件和短信的例子）
首先，創建二者的共同接口：
public interface Sender { public void Send(); }
其次，創建實現類：
public class MailSender implements Sender { @Override public void Send() { System.out.println("this is mailsender!"); } }
public class SmsSender implements Sender { @Override public void Send() { System.out.println("this is sms sender!"); } }
最后，建工廠類：
public class SendFactory { public Sender produce(String type) { if ("mail".equals(type)) { return new MailSender(); } else if ("sms".equals(type)) { return new SmsSender(); } else { System.out.println("請輸入正確的類型!"); return null; } } }
我們來測試下：
public class FactoryTest { public static void main(String[] args) { SendFactory factory = new SendFactory(); Sender sender = factory.produce("sms"); sender.Send(); } }
輸出：this is sms sender!
(2)多個工廠方法模式
該模式是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字符串出錯，則不能正確創建對象，而多個工廠方法模式是提供多個工廠方法，分別創建對象。關系圖：
將上面的代碼做下修改，改動下SendFactory類就行，如下：
public Sender produceMail(){ return new MailSender(); } public Sender produceSms(){ return new SmsSender(); } }
測試類如下：
public class FactoryTest { public static void main(String[] args) { SendFactory factory = new SendFactory(); Sender sender = factory.produceMail(); sender.Send(); } }
輸出：this is mailsender!
（3）靜態工廠方法模式
將上面的多個工廠方法模式里的方法置為靜態的，不需要創建實例，直接調用即可。
public class SendFactory { public static Sender produceMail(){ return new MailSender(); } public static Sender produceSms(){ return new SmsSender(); } }
public class FactoryTest { public static void main(String[] args) { Sender sender = SendFactory.produceMail(); sender.Send(); } }
輸出：this is mailsender!
總體來說，工廠模式適合：凡是出現了大量的產品需要創建，並且具有共同的接口時，可以通過工廠方法模式進行創建。在以上的三種模式中，第一種如果傳入的字符串有誤，不能正確創建對象，第三種相對於第二種，不需要實例化工廠類，所以，大多數情況下，我們會選用第三種——靜態工廠方法模式。
2、抽象工廠模式（Abstract Factory）
工廠方法模式有一個問題就是，類的創建依賴工廠類，也就是說，如果想要拓展程序，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，如何解決？就用到抽象工廠模式，創建多個工廠類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的代碼。因為抽象工廠不太好理解，我們先看看圖，然后就和代碼，就比較容易理解。
請看例子：
public interface Sender { public void Send(); }
兩個實現類：
public class MailSender implements Sender { @Override public void Send() { System.out.println("this is mailsender!"); } }
public class SmsSender implements Sender { @Override public void Send() { System.out.println("this is sms sender!"); } }
兩個工廠類：
public class SendMailFactory implements Provider { @Override public Sender produce(){ return new MailSender(); } }
public class SendSmsFactory implements Provider{ @Override public Sender produce() { return new SmsSender(); } }
在提供一個接口：
public interface Provider { public Sender produce(); }
測試類：
public class Test { public static void main(String[] args) { Provider provider = new SendMailFactory(); Sender sender = provider.produce(); sender.Send(); } }
其實這個模式的好處就是，如果你現在想增加一個功能：發及時信息，則只需做一個實現類，實現Sender接口，同時做一個工廠類，實現Provider接口，就OK了，無需去改動現成的代碼。這樣做，拓展性較好！
3、單例模式（Singleton）
單例模式是設計模式中最常見也最簡單的一種設計模式，保證了在程序中只有一個實例存在並且能全局的訪問到。比如在Android實際APP 開發中用到的 賬號信息對象管理， 數據庫對象（SQLiteOpenHelper）等都會用到單例模式。這樣的模式有幾個好處：
1、某些類創建比較頻繁，對於一些大型的對象，這是一筆很大的系統開銷。
2、省去了new操作符，降低了系統內存的使用頻率，減輕GC壓力。
3、有些類如交易所的核心交易引擎，控制着交易流程，如果該類可以創建多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易服務器獨立控制整個流程。下面針對一些例子分析一下我們在開發過程中應用單例模式需要注意的點。
一、作用
單例模式（Singleton）：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點
二、適用場景
1. 應用中某個實例對象需要頻繁的被訪問。
2. 應用中每次啟動只會存在一個實例。如賬號系統，數據庫系統。
三、常用的使用方式
（1）懶漢式
優點：延遲加載（需要的時候才去加載）
缺點： 線程不安全，在多線程中很容易出現不同步的情況，如在數據庫對象進行的頻繁讀寫操作時。
具體實現如下：
public class Singleton {
/* 持有私有靜態實例，防止被引用，此處賦值為null，目的是實現延遲加載 */
private static Singleton instance = null;
/* 私有構造方法，防止被實例化 */
private Singleton() {
}
/* 1:懶漢式，靜態工程方法，創建實例 */
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
（2）加同步鎖
優點：解決了線程不安全的問題。
缺點：效率有點低，每次調用實例都要判斷同步鎖
注：在Android源碼中使用的該單例方法有：InputMethodManager，AccessibilityManager等都是使用這種單例模式。
具體代碼如下：
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
或
/*加上synchronized，但是每次調用實例時都會加載**/
public static Singleton getInstance() {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
return instance;
}
（3）雙重檢驗鎖
要優化（2）中因為每次調用實例都要判斷同步鎖的問題，很多人都使用下面的一種雙重判斷校驗的辦法。
優點：在並發量不多，安全性不高的情況下或許能很完美運行單例模式
缺點：不同平台編譯過程中可能會存在嚴重安全隱患。
補充：在android圖像開源項目Android-Universal-Image-Loader （https://github.com/nostra13/Android-Universal-Image-Loader）中使用的是這種方式。
/*3.雙重鎖定:只在第一次初始化的時候加上同步鎖*/
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
這種方法貌似很完美的解決了上述效率的問題，它或許在並發量不多，安全性不太高的情況能完美運行，但是，這種方法也有不幸的地方。問題就是出現在這句
instance = new Singleton();
在JVM編譯的過程中會出現指令重排的優化過程，這就會導致當 instance實際上還沒初始化，就可能被分配了內存空間，也就是說會出現 instance !=null 但是又沒初始化的情況，這樣就會導致返回的 instance 不完整（可以參考：http://www.360doc.com/content/11/0810/12/1542811_139352888.shtml）。
（4）內部類的實現
優點：延遲加載，線程安全（java中class加載時互斥的），也減少了內存消耗。內部類是一種好的實現方式，可以推薦使用一下：
public class SingletonInner { private static class SingletonHolder { private static SingletonInner instance = new SingletonInner(); } /** * 私有的構造函數 */ private SingletonInner() { } public static SingletonInner getInstance() { return SingletonHolder.instance; } protected void method() { System.out.println("SingletonInner"); } }
（5）枚舉的方法
這是網上很多人推薦的一種做法，但是貌似使用的不廣泛，大家可以試試，具體代碼如下：
public enum SingletonEnum { /** * 1.從Java1.5開始支持; * 2.無償提供序列化機制; * 3.絕對防止多次實例化，即使在面對復雜的序列化或者反射攻擊的時候; */ instance; private String others; SingletonEnum() { } public void method() { System.out.println("SingletonEnum"); } public String getOthers() { return others; } public void setOthers(String others) { this.others = others; } }
通過單例模式的學習告訴我們：
1、單例模式理解起來簡單，但是具體實現起來還是有一定的難度。
2、synchronized關鍵字鎖定的是對象，在用的時候，一定要在恰當的地方使用（注意需要使用鎖的對象和過程，可能有的時候並不是整個對象及整個過程都需要鎖）。
到這兒，單例模式基本已經講完了，結尾處，筆者突然想到另一個問題，就是采用類的靜態方法，實現單例模式的效果，也是可行的，此處二者有什么不同？
首先，靜態類不能實現接口。（從類的角度說是可以的，但是那樣就破壞了靜態了。因為接口中不允許有static修飾的方法，所以即使實現了也是非靜態的）
其次，單例可以被延遲初始化，靜態類一般在第一次加載是初始化。之所以延遲加載，是因為有些類比較龐大，所以延遲加載有助於提升性能。
再次，單例類可以被繼承，他的方法可以被覆寫。但是靜態類內部方法都是static，無法被覆寫。
最后一點，單例類比較靈活，畢竟從實現上只是一個普通的Java類，只要滿足單例的基本需求，你可以在里面隨心所欲的實現一些其它功能，但是靜態類不行。從上面這些概括中，基本可以看出二者的區別，但是，從另一方面講，我們上面最后實現的那個單例模式，內部就是用一個靜態類來實現的，所以，二者有很大的關聯，只是我們考慮問題的層面不同罷了。兩種思想的結合，才能造就出完美的解決方案，就像HashMap采用數組+鏈表來實現一樣，其實生活中很多事情都是這樣，單用不同的方法來處理問題，總是有優點也有缺點，最完美的方法是，結合各個方法的優點，才能最好的解決問題！
關於其他的模式詳見文章轉載文章於：http://zz563143188.iteye.com/blog/1847029