莊周夢蝶

來自javayeye的帖子，http://www.javaeye.com/topic/18648?page=1，運用設計模式很重要一點：模式應該帶來清晰并且易于理解的結構，而非大堆大堆的麻煩。如果是你發現變麻煩了，那是你的方法錯了。設計模式的異同不是通過結構，而是通過意圖和場景來理解，當然，如果真能達到應用中重神而非形的境界，就玄而又玄了。

工廠模式是最重要的模式，因為大多數模式都需要用到工廠模式。如果不能正確的運用工廠模式，那么可以說無法成為合格的架構師。
多數設計模式的內容講解的都是如何設計接口。
接口如何產生呢？如果在客戶代碼（類庫的使用者稱之為客戶）中直接使用具體類，那么就失去了接口的意義。因為接口的使用目的，就是要降低客戶對具 體類的依賴程度。如果在客戶代碼中直接使用接口，那么就造成了客戶對具體類名稱的依賴。（客戶最終需要以某種方式指明所需要的具體類，如配置文件或代碼， 但是只需要指出一次，所以說降低對具體類的依賴程度）。要使客戶代碼不依賴具體類，唯一的方法，就是讓客戶代碼不依賴具體類的部分不知道具體類的名稱。知 道具體類名稱的部分，僅僅是配置部分。（配置文件或者配置代碼）。
依賴不可能完全消除，除非二者毫無聯系。但是可以將這種依賴的程度降到最低。
既然不能直接創建具體類，那么就需要通過一個創建者類來創建接口的實現類。這樣就產生了工廠類。
那么現在已經知道工廠類存在的理由，抽象創建接口的過程。
這樣，就可以使用簡單工廠。
簡單工廠，一般是兩級結構。工廠類創建接口。
隨著接口創建復雜性的增強，可能在接口創建的過程中，一個創建者類，無法承擔創建所有的接口類的職責。
可能會有這樣的情況，我們定義了一個接口，有6個實現類分別是123456號。但是，這六個實現類不可能用一個工廠創建出來，因為123號是 windows下的實現，而456號是linux上的實現。（假設我們使用的語言不是廣大人民群眾熱愛的java語言），那么這個時候，我還需要客戶方用 相同的方式來創建這個借口，而不是在代碼中到處寫

那樣就太麻煩了。設計模式就是為了減少麻煩，而不是什么別的廢話，比如什么太極八卦、天人合一、面向xx之類的。因為怕麻煩，所以搞出設計模式這個咚咚減少麻煩。如果你發現用了設計模式更麻煩了，那么肯定是你用錯了。
這個時候為了省事，我就把工廠也抽象成一個接口（因為我有兩個相似的工廠，如果只有一個，我還廢話什么呢），這樣就成了工廠方法。
當然，既然工廠方法成了一個接口，那么當然也需要用一個工廠來創建它。這個時候，創建是三級結構，簡單工廠（此時是工廠的工廠）創建工廠接口（本來是個類，現在因為進一步的抽象，成為接口了），工廠接口創建產品。
過了一段時間，隨著我們的工廠業務不斷發展，我們有了很多產品。
比如，我們有錘子和釘子兩種產品。這兩種產品都有windows品牌和linux品牌的。我們給錘子和釘子各自定義了一個創建的接口。

可是，我們發現某些用戶，用windows的錘子去敲linux的釘子，從而把程序敲出了bug。這當然是我們的錯誤，因為我們違反了一條金科玉律：
要想使你的程序穩定運行，你假設用戶是豬。
所以，我們把錘子和釘子的工廠合并，讓一個工廠只能造出配套的錘子和釘子，這樣豬就沒有犯錯誤的機會了。
于是我們搞出一個抽象工廠：

當然，這個鐵匠鋪是個接口，所以同樣需要用一個工廠來創建它。所以，這個時候，工廠還是三級結構。
我們的工廠，業務很多，而且產品一般都是配套使用的（這樣可以多騙點錢），所以，我們大多數情況下，都是使用抽象工廠和簡單工廠。簡單工廠用來創建工廠，抽象工廠創建產品。
工廠的作用，就是創建接口。
其實我們不知道什么是設計模式，我們只是怕麻煩。什么是麻煩呢？
我們覺得把同樣的代碼寫兩遍就非常麻煩。所以，我們寧可多寫幾句，也要解決麻煩。豬不怕麻煩，可以日復一日的重復相同的事情，可是我們不是豬。