瞭解設計模式的朋友們，想必都聽說過“六大設計原則”吧。其實最經典的 23 種設計模式中或多或少地都在使用這些設計原則，也就是說，設計模式是站在設計原則的基礎之上的。所以在學習設計模式之前，很有必要對這些設計原則先做一下了解。
1、單一職責原則
There should never be more than one reason for a class to change.
理解：不同的類具備不同的職責，各司其職。做系統設計是，如果發現有一個類擁有了兩種職責，那麼就要問一個問題：可以將這個類分成兩個類嗎？如果真的有必要，那就分開，千萬不要讓一個類乾的事情太多。
總結：一個類只承擔一個職責
2、開放封閉原則
Software entities like classes,modules and functions should be open for extension but closed for modifications.
理解：類、模塊、函數，可以去擴展，但不要去修改。如果要修改代碼，儘量用繼承或組合的方式來擴展類的功能，而不是直接修改類的代碼。當然，如果能保證對整個架構不會產生任何影響，那就沒必要搞的那麼複雜，直接改這個類吧。
總結：對軟件實體的改動，最好用擴展而非修改的方式。
3、裏式替換原則
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
理解：父類可被子類替換，但反之不一定成立。也就是說，代碼中可以將父類全部替換爲子類，程序不會出現異常，但反過來就不一定了。
總結：在繼承類是，務必重寫（override）父類中所有的方法，尤其需要注意父類的protected方法（它們往往是讓你重寫的），子類儘量不要暴露自己的public方法供外界調用。
4、最少知識原則
Only talk to you immediate friends.
理解：儘量減少對象之間的交互，從而減小類之間的耦合。在做系統設計時，不要讓一個類依賴於太多其他的類，需儘量減小依賴關係，否則死都不知道怎麼死的。
總結：一定要做到：低耦合、高內聚。
5、接口隔離原則
The dependency of one class to another one should depend on the smallest possible interface.
理解：不要對外暴露沒有實際意義的接口。也就是說，儘量保證接口的實用性。當需要對外暴露接口時，需要再三斟酌，若沒必要對外提供就刪了吧，因爲一旦提供了就意味着，將來要多做一件事情，何苦給自己找事做呢。
總結：不要對外暴露沒有實際意義的接口。
6、依賴倒置原則
High level modules should not depends upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.
理解：高層模塊不應該依賴於底層模塊，而應該依賴於抽象。抽象不應依賴於細節，細節應依賴於抽象。應該面向接口編程，不該面向實現類編程。面向實現類編程相當於就事論事，那是正向依賴；面向接口編程，相當於透過現象看本質，抓住事務的共性，那就是反向依賴，即依賴倒置。
總結：面向接口編程，提取出事務的本質和共性。
將六大原則的英文首字母拼在一起就是SOLID（穩定的），所以也稱之爲SOLID原則。
只有滿足了這六大原則，才能設計出穩定的軟件架構，但它們只是原則，有時還是需要學會靈活應變，千萬不要生搬硬套，否則只會把簡單問題複雜化，切記！
23中設計模式轉自：http://zz563143188.iteye.com/blog/1847029
最經典的 23 種設計模式中或多或少地都在使用這些設計原則，也就是說，設計模式是站在設計原則的基礎之上的。下面來詳細介紹Java中23種設計模式的概念，應用場景等情況，並結合他們的特點及設計模式的原則進行分析。
總體來說23種設計模式分爲三大類：
創建型模式（5種）：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式（7種）：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行爲型模式（11種）：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
1、工廠方法模式
1.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!
1.2多個工廠方法模式：是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字符串出錯，則不能正確創建對象，而多個工廠方法模式是提供多個工廠方法，分別創建對象。
將上面的代碼做下修改，改動下SendFactory類就行，如下：
- 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!
1.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!
總體來說，工廠模式適合：凡是出現了大量的產品需要創建，並且具有共同的接口時，可以通過工廠方法模式進行創建。在以上的三種模式中，第一種如果傳入的字符串有誤，不能正確創建對象，第三種相對於第二種，不需要實例化工廠類，所以，大多數情況下，我們會選用第三種——靜態工廠方法模式。
1.4抽象工廠模式：工廠方法模式有一個問題就是，類的創建依賴工廠類，也就是說，如果想要拓展程序，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，如何解決？就用到抽象工廠模式，創建多個工廠類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的代碼。
請看例子：
- 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了，無需去改動現成的代碼。這樣做，拓展性較好！
2、單例模式
單例對象（Singleton）是一種常用的設計模式。在Java應用中，單例對象能保證在一個JVM中，該對象只有一個實例存在。這樣的模式有幾個好處：
1、某些類創建比較頻繁，對於一些大型的對象，這是一筆很大的系統開銷。
2、省去了new操作符，降低了系統內存的使用頻率，減輕GC壓力。
3、有些類如交易所的核心交易引擎，控制着交易流程，如果該類可以創建多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易服務器獨立控制整個流程。
首先我們寫一個簡單的單例類：
- public class Singleton {
- /* 持有私有靜態實例，防止被引用，此處賦值爲null，目的是實現延遲加載 */
- private static Singleton instance = null;
- /* 私有構造方法，防止被實例化 */
- private Singleton() {
- }
- /* 靜態工程方法，創建實例 */
- public static Singleton getInstance() {
- if (instance == null) {
- instance = new Singleton();
- }
- return instance;
- }
- /* 如果該對象被用於序列化，可以保證對象在序列化前後保持一致 */
- public Object readResolve() {
- return instance;
- }
- }
這個類可以滿足基本要求，但是，像這樣毫無線程安全保護的類，如果我們把它放入多線程的環境下，肯定就會出現問題了，如何解決？我們首先會想到對getInstance方法加synchronized關鍵字，如下：
- public static synchronized Singleton getInstance() {
- if (instance == null) {
- instance = new Singleton();
- }
- return instance;
- }
但是，synchronized關鍵字鎖住的是這個對象，這樣的用法，在性能上會有所下降，因爲每次調用getInstance()，都要對對象上鎖，事實上，只有在第一次創建對象的時候需要加鎖，之後就不需要了，所以，這個地方需要改進。我們改成下面這個：
- public static Singleton getInstance() {
- if (instance == null) {
- synchronized (instance) {
- if (instance == null) {
- instance = new Singleton();
- }
- }
- }
- return instance;
- }
似乎解決了之前提到的問題，將synchronized關鍵字加在了內部，也就是說當調用的時候是不需要加鎖的，只有在instance爲null，並創建對象的時候才需要加鎖，性能有一定的提升。但是，這樣的情況，還是有可能有問題的，看下面的情況：在Java指令中創建對象和賦值操作是分開進行的，也就是說instance = new Singleton();語句是分兩步執行的。但是JVM並不保證這兩個操作的先後順序，也就是說有可能JVM會爲新的Singleton實例分配空間，然後直接賦值給instance成員，然後再去初始化這個Singleton實例。這樣就可能出錯了，我們以A、B兩個線程爲例：
a>A、B線程同時進入了第一個if判斷
b>A首先進入synchronized塊，由於instance爲null，所以它執行instance = new Singleton();
c>由於JVM內部的優化機制，JVM先畫出了一些分配給Singleton實例的空白內存，並賦值給instance成員（注意此時JVM沒有開始初始化這個實例），然後A離開了synchronized塊。
d>B進入synchronized塊，由於instance此時不是null，因此它馬上離開了synchronized塊並將結果返回給調用該方法的程序。
e>此時B線程打算使用Singleton實例，卻發現它沒有被初始化，於是錯誤發生了。
所以程序還是有可能發生錯誤，其實程序在運行過程是很複雜的，從這點我們就可以看出，尤其是在寫多線程環境下的程序更有難度，有挑戰性。我們對該程序做進一步優化：
- private static class SingletonFactory{
- private static Singleton instance = new Singleton();
- }
- public static Singleton getInstance(){
- return SingletonFactory.instance;
- }
實際情況是，單例模式使用內部類來維護單例的實現，JVM內部的機制能夠保證當一個類被加載的時候，這個類的加載過程是線程互斥的。這樣當我們第一次調用getInstance的時候，JVM能夠幫我們保證instance只被創建一次，並且會保證把賦值給instance的內存初始化完畢，這樣我們就不用擔心上面的問題。同時該方法也只會在第一次調用的時候使用互斥機制，這樣就解決了低性能問題。這樣我們暫時總結一個完美的單例模式：
- public class Singleton {
- /* 私有構造方法，防止被實例化 */
- private Singleton() {
- }
- /* 此處使用一個內部類來維護單例 */
- private static class SingletonFactory {
- private static Singleton instance = new Singleton();
- }
- /* 獲取實例 */
- public static Singleton getInstance() {
- return SingletonFactory.instance;
- }
- /* 如果該對象被用於序列化，可以保證對象在序列化前後保持一致 */
- public Object readResolve() {
- return getInstance();
- }
- }
其實說它完美，也不一定，如果在構造函數中拋出異常，實例將永遠得不到創建，也會出錯。所以說，十分完美的東西是沒有的，我們只能根據實際情況，選擇最適合自己應用場景的實現方法。也有人這樣實現：因爲我們只需要在創建類的時候進行同步，所以只要將創建和getInstance()分開，單獨爲創建加synchronized關鍵字，也是可以的：
- public class SingletonTest {
- private static SingletonTest instance = null;
- private SingletonTest() {
- }
- private static synchronized void syncInit() {
- if (instance == null) {
- instance = new SingletonTest();
- }
- }
- public static SingletonTest getInstance() {
- if (instance == null) {
- syncInit();
- }
- return instance;
- }
- }
考慮性能的話，整個程序只需創建一次實例，所以性能也不會有什麼影響。
補充：採用"影子實例"的辦法爲單例對象的屬性同步更新
- public class SingletonTest {
- private static SingletonTest instance = null;
- private Vector properties = null;
- public Vector getProperties() {
- return properties;
- }
- private SingletonTest() {
- }
- private static synchronized void syncInit() {
- if (instance == null) {
- instance = new SingletonTest();
- }
- }
- public static SingletonTest getInstance() {
- if (instance == null) {
- syncInit();
- }
- return instance;
- }
- public void updateProperties() {
- SingletonTest shadow = new SingletonTest();
- properties = shadow.getProperties();
- }
- }
通過單例模式的學習告訴我們：
1、單例模式理解起來簡單，但是具體實現起來還是有一定的難度。
2、synchronized關鍵字鎖定的是對象，在用的時候，一定要在恰當的地方使用（注意需要使用鎖的對象和過程，可能有的時候並不是整個對象及整個過程都需要鎖）。
到這兒，單例模式基本已經講完了，結尾處，筆者突然想到另一個問題，就是採用類的靜態方法，實現單例模式的效果，也是可行的，此處二者有什麼不同？
首先，靜態類不能實現接口。（從類的角度說是可以的，但是那樣就破壞了靜態了。因爲接口中不允許有static修飾的方法，所以即使實現了也是非靜態的）
其次，單例可以被延遲初始化，靜態類一般在第一次加載是初始化。之所以延遲加載，是因爲有些類比較龐大，所以延遲加載有助於提升性能。
再次，單例類可以被繼承，他的方法可以被覆寫。但是靜態類內部方法都是static，無法被覆寫。
最後一點，單例類比較靈活，畢竟從實現上只是一個普通的Java類，只要滿足單例的基本需求，你可以在裏面隨心所欲的實現一些其它功能，但是靜態類不行。從上面這些概括中，基本可以看出二者的區別，但是，從另一方面講，我們上面最後實現的那個單例模式，內部就是用一個靜態類來實現的，所以，二者有很大的關聯，只是我們考慮問題的層面不同罷了。兩種思想的結合，才能造就出完美的解決方案，就像HashMap採用數組+鏈表來實現一樣，其實生活中很多事情都是這樣，單用不同的方法來處理問題，總是有優點也有缺點，最完美的方法是，結合各個方法的優點，才能最好的解決問題！
3、建造者模式
工廠類模式提供的是創建單個類的模式，而建造者模式則是將各種產品集中起來進行管理，用來創建複合對象，所謂複合對象就是指某個類具有不同的屬性，其實建造者模式就是前面抽象工廠模式和最後的Test結合起來得到的。我們看一下代碼：
還和前面一樣，一個Sender接口，兩個實現類MailSender和SmsSender。最後，建造者類如下：
- public class Builder {
- private List<Sender> list = new ArrayList<Sender>();
- public void produceMailSender(int count){
- for(int i=0; i<count; i++){
- list.add(new MailSender());
- }
- }
- public void produceSmsSender(int count){
- for(int i=0; i<count; i++){
- list.add(new SmsSender());
- }
- }
- }
測試類：
- public class Test {
- public static void main(String[] args) {
- Builder builder = new Builder();
- builder.produceMailSender(10);
- }
- }
從這點看出，建造者模式將很多功能集成到一個類裏，這個類可以創造出比較複雜的東西。所以與工廠模式的區別就是：工廠模式關注的是創建單個產品，而建造者模式則關注創建符合對象，多個部分。因此，是選擇工廠模式還是建造者模式，依實際情況而定。
4、原型模式原型模式雖然是創建型的模式，但是與工程模式沒有關係，從名字即可看出，該模式的思想就是將一個對象作爲原型，對其進行復制、克隆，產生一個和原對象類似的新對象。本小結會通過對象的複製，進行講解。在Java中，複製對象是通過clone()實現的，先創建一個原型類：
- public class Prototype implements Cloneable {
- public Object clone() throws CloneNotSupportedException {
- Prototype proto = (Prototype) super.clone();
- return proto;
- }
- }
很簡單，一個原型類，只需要實現Cloneable接口，覆寫clone方法，此處clone方法可以改成任意的名稱，因爲Cloneable接口是個空接口，你可以任意定義實現類的方法名，如cloneA或者cloneB，因爲此處的重點是super.clone()這句話，super.clone()調用的是Object的clone()方法，而在Object類中，clone()是native的，具體怎麼實現，我會在另一篇文章中，關於解讀Java中本地方法的調用，此處不再深究。在這兒，我將結合對象的淺複製和深複製來說一下，首先需要了解對象深、淺複製的概念：
淺複製：將一個對象複製後，基本數據類型的變量都會重新創建，而引用類型，指向的還是原對象所指向的。
深複製：將一個對象複製後，不論是基本數據類型還有引用類型，都是重新創建的。簡單來說，就是深複製進行了完全徹底的複製，而淺複製不徹底。
此處，寫一個深淺複製的例子：
- public class Prototype implements Cloneable, Serializable {
- private static final long serialVersionUID = 1L;
- private String string;
- private SerializableObject obj;
- /* 淺複製 */
- public Object clone() throws CloneNotSupportedException {
- Prototype proto = (Prototype) super.clone();
- return proto;
- }
- /* 深複製 */
- public Object deepClone() throws IOException, ClassNotFoundException {
- /* 寫入當前對象的二進制流 */
- ByteArrayOutputStream bos = new ByteArrayOutputStream();
- ObjectOutputStream oos = new ObjectOutputStream(bos);
- oos.writeObject(this);
- /* 讀出二進制流產生的新對象 */
- ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
- ObjectInputStream ois = new ObjectInputStream(bis);
- return ois.readObject();
- }
- public String getString() {
- return string;
- }
- public void setString(String string) {
- this.string = string;
- }
- public SerializableObject getObj() {
- return obj;
- }
- public void setObj(SerializableObject obj) {
- this.obj = obj;
- }
- }
- class SerializableObject implements Serializable {
- private static final long serialVersionUID = 1L;
- }
