《軟體設計精要與模式》讀書筆記(五)&原廠模式資料匯總&提議

     在寫這篇隨筆的時候，我考慮了很久，第一，其實在部落格園中已經有很多篇關於原廠模式的隨筆了，如果我再繼續寫，我發現我也超不過前面已經寫過的“前輩”：）；第二，《軟體設計精要與模式》的第二篇第六章個人感覺寫的也不是特別好，僅僅可以作為初步學習原廠模式的資料來參考，我再把這些讀書筆記寫出來也沒有太多意義。所以我寫這篇讀書筆記將部落格園裡面關於原廠模式寫的比較好的資料給大家整理出來，方便瀏覽。

     另外部落格園裡面關於工廠資料的重複資料太多了，建議大家以後寫的時候先看看有沒有，你自己寫出來可以方便自己和大家，這種我們大家鼓勵和讚揚，但是盡寫些重複的東西就是你的不對了，更大的不是就是你還發表出來占首頁。。。;還有，希望別人在轉摘別人的內容時，能夠註明出處，我今天瀏覽別人隨筆時，發現有轉帖的，但是沒有看到出處，我想引用的時候，不知道原作者。所以我引用了作者文章，但是由於不知道原作者而沒有註明的，希望原作者不要介意或者跟我說明我將更新隨筆；第三，如果在自己部落格裡面附加源碼的，最好能夠說明一下源碼使用環境，比如.NET2003+MSSQL等等，同時建議不要使用太高版本的源碼環境。

     這裡還要說明一下，我之所以將這篇文章放在部落格園首頁，是因為我對我上面的三個提議考慮再三，決定將這篇隨筆放在首頁，並不是因為我轉摘了一些大家的文章，如果大家因為此對我有意見，我這裡也先跟大家道歉了。

     

     首先，原廠模式的一些基本資料大家還是要知道的：(這裡有部分資料是從一些部落格裡面摘抄的，我的隨便後面會註明參考資料。)

     《設計模式》中是這樣說明：定義一個用於建立對象的介面，讓子類決定執行個體化那個類。FactoryMethod使得一個類的執行個體化延遲到子類。

     1.抽象工廠是一種建立型模式，是為瞭解決執行個體化時所帶來的問題。

     2.抽象工廠有簡單工廠、Factory 方法、抽象工廠和反射工廠；

     3.使用抽象原廠模式的條件：
          a) 一個系統不應依賴於產品如何被建立，組合和表達的細節;
          b)有多個產品族，而系統只消費其中一個族中的產品;
          c)同屬於一個產品族的產品是在一起使用的;
          d)系統提供一個產品的庫，所有產品都是以同樣的介面實現。

     4. Abstract Factory模式的幾個要點：
          a)如果沒有應對“多系列對象構建”的需求變化，則沒有必要使用Abstract Factory模式。
          b)“系列對象”指的是這項對象之間有相互依賴、或作用的關係。
          c)Abstract Factory模式主要在於應對“新系列”的需求變動。缺點是難以應對“新對象”的需求變動。這一點應該注意，就像前面說的，如果我們現在要在加入其他系列的類，代碼的改動會很大。
          d)Abstract Factory模式經常和Factory Method模式共同組合來應對“對象建立”的需求變化。

     5.抽象工廠通用原則：在可能的情況下盡量使用基類的方法
           與簡單抽象工廠的區別:
               a）Factory用於建立一種類型的產品，而AbstractFactory用於建立產品族
          抽象工廠的各種角色:
               a).抽象工廠(Abstract Factory).   擔任這個角色的是Factory 方法模式的核心，它是與應用程式無關的。任何在模式中創立對象的工廠類必須實現這個介面，或繼承這個類。 
               b).具體工廠(Concrete Factory).   這個角色直接在用戶端的調用下建立產品的執行個體。這個角色含有選擇合適的產品對象的邏輯，而這個邏輯是與應用系統的商業邏輯緊密相關的。

               c).抽象產品(Abstract Product).  擔任這個角色的類是Factory 方法模式所建立的對象的父類，或它們共同擁有的介面。 
               d).具體產品(Concrete Factory).  抽象原廠模式所建立的任何產品對象都是某一個具體產品類的執行個體。這是用戶端最終需要的東西，其內部一定充滿了應用系統的商業邏輯。

     6.反射工廠的優缺點

          使用反射工廠的優點是極大地減少了工廠類的數量、降低了代碼的冗餘，並且系統更容易擴充，在增加新類型後，不需要修改工廠類。
          使用反射工廠的代價是工廠與產品之間的依賴關係不明顯，由於是動態綁定，因此理論上可以用一個工廠完成很多類型的執行個體化，從而使得代碼 不容易理解。另外增大了測試難度，建立是動態完成的，測試案例的編寫和測試執行要比傳統的工廠困難。

 

     這是我整理出來個人覺得有參考價值的資料，方便大家參考：

     1.簡單工廠

     缺點：不能應對“不同系列對象的變化”；

     由淺入深學“原廠模式”(1)

     解讀設計模式----簡單原廠模式(SimpleFactory Pattern),你要什麼我就給你什麼

     2.Factory 方法

     由淺入深學“原廠模式”(2)

     3.抽象工廠

     由淺入深學“原廠模式”(3)

     4.反射工廠

     範型類型原廠模式(這篇寫的一般，但是還是拋個磚吧)

     Dot NET設計模式—反射工廠

     5.綜合

     原廠模式兄弟姐妹

     

     另外，由於自己整理這篇文章難免會漏掉一些比較好的文章，希望大家跟帖，我將隨時更新隨筆。 

 

 

參考資料:

     設計模式學習筆記（三）——Abstract Factory抽象原廠模式 

     抽象原廠模式

     FactoryMethod原廠模式 

     Abstract Factory 抽象原廠模式小結