1. 概述：

　　將一個(gè)具體類的實(shí)例化交給一個(gè)靜態(tài)工廠方法來執(zhí)行，它不屬于GOF的23種設(shè)計(jì)模式，但現(xiàn)實(shí)中卻經(jīng)常會用到

2. 模式中的角色

　　2.1 工廠類（Simple Factory): 只包含了創(chuàng)建具體類的靜態(tài)方法。

　　2.2 抽象產(chǎn)品（Product）：定義簡單工廠中要返回的產(chǎn)品。

　　2.3 具體產(chǎn)品（ConcreteProduct）：具體產(chǎn)品。

3. 模式解讀

　　3.1 簡單工廠模式的一般化類圖

　　3.2 簡單工廠模式的代碼實(shí)現(xiàn)

 /// <summary>
 /// 簡單工廠類，用sealed修飾，
 /// </summary>
 public class SimpleProductFactory
 {
  /// <summary>
  /// 使用靜態(tài)方法，根據(jù)傳入的參數(shù)來指定要實(shí)例化哪一種產(chǎn)品
  /// </summary>
  /// <param name="productType"></param>
  /// <returns></returns>
  public static Product CreateProduct(string productType)
  {
   Product product = null;
   switch (productType)
   {
    case "A":
     product = new ConcreteProductA();
     break;
    case "B":
     product = new ConcreteProductB();
     break;
   }

   return product;
  }
 }

 /// <summary>
 /// 抽象產(chǎn)品
 /// </summary>
 public abstract class Product
 {
  public Product()
  { }

  public abstract void Opration();
 }

 /// <summary>
 /// 具體產(chǎn)品 A
 /// </summary>
 public class ConcreteProductA : Product
 {
  public ConcreteProductA() { }

  public override void Opration()
  {
   // 產(chǎn)品A
  }
 }

 /// <summary>
 /// 具體產(chǎn)品 B
 /// </summary>
 public class ConcreteProductB : Product
 {
  public ConcreteProductB() { }

  public override void Opration()
  {
   //產(chǎn)品B
  }
 }

4. 模式總結(jié)

　　4.1 優(yōu)點(diǎn)：
　　　　4.1.1 職責(zé)單一，實(shí)現(xiàn)簡單，且實(shí)現(xiàn)了客戶端代碼與具體實(shí)現(xiàn)的解耦。

　　　　4.1.2 工廠類是整個(gè)模式的關(guān)鍵.包含了必要的邏輯判斷,根據(jù)外界給定的信息,決定究竟應(yīng)該創(chuàng)建哪個(gè)具體類的對象.

　　　　4.1.3 通過使用工廠類,外界可以從直接創(chuàng)建具體產(chǎn)品對象的尷尬局面擺脫出來,僅僅需要負(fù)責(zé)“消費(fèi)”對象就可以了。而不必管這些對象究竟如何創(chuàng)建及如何組織的．

　　　　4.1.4 明確了各自的職責(zé)和權(quán)利，有利于整個(gè)軟件體系結(jié)構(gòu)的優(yōu)化。
　　4.2 缺點(diǎn)：
　　　　4.2.1 由于工廠類集中了所有實(shí)例的創(chuàng)建邏輯，違反了高內(nèi)聚責(zé)任分配原則，將全部創(chuàng)建邏輯集中到了一個(gè)工廠類中；它所能創(chuàng)建的類只能是事先考慮到的，如果需要添加新的類，則就需要改變工廠類了。因此它是違背開放封閉原則的。
　　　　4.2.2 當(dāng)系統(tǒng)中的具體產(chǎn)品類不斷增多時(shí)候，可能會出現(xiàn)要求工廠類根據(jù)不同條件創(chuàng)建不同實(shí)例的需求．這種對條件的判斷和對具體產(chǎn)品類型的判斷交錯(cuò)在一起，很難避免模塊功能的蔓延，對系統(tǒng)的維護(hù)和擴(kuò)展非常不利；
　　　　注：這些缺點(diǎn)在工廠方法模式中得到了一定的克服。
　　4.3 使用場景：
　　　　4.3.1 工廠類負(fù)責(zé)創(chuàng)建的對象比較少；
　　　　4.3.2 客戶只知道傳入工廠類的參數(shù)，對于如何創(chuàng)建對象（邏輯）不關(guān)心；
　　　　4.3.3 由于簡單工廠很容易違反高內(nèi)聚責(zé)任分配原則，因此一般只在很簡單的情況下應(yīng)用。

以上就是本文的全部內(nèi)容，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評論