實際開發中哪些情境需要用到原廠模式？

Factory 方法模式可以允許系統在不修改工廠角色的情況下引進新產品。

1. 原廠模式

2. 簡單原廠模式

3. 抽象原廠模式

請問實際開發中哪些情況下會用到它？為什麼我感覺我現在開發很少會用到這些設計模式啊。。。

回複內容：

Factory 方法模式可以允許系統在不修改工廠角色的情況下引進新產品。

1. 原廠模式

2. 簡單原廠模式

3. 抽象原廠模式

請問實際開發中哪些情況下會用到它？為什麼我感覺我現在開發很少會用到這些設計模式啊。。。

我先說下 我目前看到用到了原廠模式的例子：

一般的MVC架構中，都有一個基本的DB資料庫基本操作類
我叫它DB class，有一個baseModel class 去繼承 db class
baseModel 是所有架構model的基類，需要繼承baseModel
baseModel已經有db類的 增刪查改的方法了，baseModel其實就是資料庫工廠，不同的模型繼承baseModel，就有操作不同資料表的對象執行個體了，這樣就用一個基礎的class 完成了執行個體化各個不同資料表的對象，就好像是工廠一樣，傳不同的表名字就返回給你不同的對象。
我的理解就是這樣的，如有誤，還請包涵和斧正。

原廠模式是一個用於執行個體化對象的模式，是用Factory 方法代替new操作的一種方式。原廠模式在Java項目中到處都是，因為原廠模式就相當於建立執行個體對象的new，如在我們的系統中經常需要記日誌，如果建立logger執行個體時所做的初始化工作可能是很長一段代碼，可能要初始化、賦值、查詢資料等等，則會導致代碼臃腫而難看。

    private static Logger    logger = LoggerFactory.getLogger(MyBusinessRPC.class);     public static Logger getLogger(String name) {    ILoggerFactory iLoggerFactory = getILoggerFactory();    return iLoggerFactory.getLogger(name);  }public static ILoggerFactory getILoggerFactory() {    if (INITIALIZATION_STATE == UNINITIALIZED) {      INITIALIZATION_STATE = ONGOING_INITIALIZATION;      performInitialization();    }    switch (INITIALIZATION_STATE) {      case SUCCESSFUL_INITIALIZATION:        return StaticLoggerBinder.getSingleton().getLoggerFactory();      case NOP_FALLBACK_INITIALIZATION:        return NOP_FALLBACK_FACTORY;      case FAILED_INITIALIZATION:        throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG);      case ONGOING_INITIALIZATION:        // support re-entrant behavior.        // See also http://bugzilla.slf4j.org/show_bug.cgi?id=106        return TEMP_FACTORY;    }    throw new IllegalStateException("Unreachable code");  }

想理解原廠模式的話就不能不知道簡單原廠模式了。

 switch ($type) {       case '存款職員': $man = new Depositer;       break;      case '銷售': $man = new Marketer;       break;       case '接待': $man = new Receiver;       break;       default: echo '傳輸參數有誤，不屬於任何一個職位';       break;   }

諾，這就是簡單原廠模式，是不是很常見，簡單原廠模式有一個不足，他雖然遵循了單一職責原則，但它違反了另一條很重要的原則：開放封閉原則。如果新增一個文員職位，那麼我們還要修改對應代碼，增加一個case，這是很可怕的，因為寫好的代碼如果我們再去修改可能會造成未知的效果。

而原廠模式就是對簡單工廠的一次升級，這裡以MVC裡的DB class來說明，外部調用的時候只需選擇自己所需的表名，該工廠會去調用真實資料庫處理方法，然後返回你想要的結果。

不論是原廠模式還是其它建立型模式，都是一個目的——為了初始化一個對象。或者說，為了構建一個資料結構模型（類和對象本身就是一種自訂的資料結構）。

那麼，問題來了，為什麼有 new 這樣方式可以建立一個對象，還要使用設計模式。本質上就是一個原因，不想讓上層使用者直接使用 new 來初始化對象。

這樣的原因有很多，絕大多數原因就是對上層的使用者隔離對象建立的過程；或者是對象建立的過程複雜，使用者不容易掌握；或者是對象建立要滿足某種條件，這些條件是業務的需求也好，是系統約束也好，沒有必要讓上層使用者掌握，增加別人開發的難度。

所以，到這時我們應該清楚了，無論是原廠模式，還是上面的戰友說的開閉原則，都是為了隔離一些複雜的過程，使得這些複雜的過程不向外暴露，如果暴露了這些過程，會對使用者增加麻煩，這也就是所謂的團隊合作。

物件導向封裝的本身也就是為了使得對外的 API 儘可能的簡化。

例如，你定義了一個 Status欄位，但這個欄位因為某些業務原因，需要使用整數來表示狀態。那麼，如果數字少了還好辦，如果數字多了，上層使用者就不一定能記清楚每個數字代表的狀態（比如你要做語音通訊系統，那麼，語音裝置是有很多狀態數位）。這時，如果使用 new來建立對象，然後再對 Status 進行賦值，不可避免的，可能要查閱開發文檔，或者會不小心給出一個錯誤的值。這時，你就不妨使用原廠模式，或者其它合適的設計模式，來進行代碼的建設。

比如，這樣：

public static class Factory{    public static Ixxxxxx CreateWithOpen()    {        var obj = new Obj();        obj.Status = 1;        return obj;    }    public static Ixxxxxx CreateWithClose()    {        var obj = new Obj();        obj.Status = 2;        return obj;    }}

當然，使用枚舉也行，這個說白了，就是看設計者的意願了。

所以，設計模式沒有說必需在哪個情境中使用，更確切的說，應該是，當你使用了設計模式，能不能為你的團隊成員帶來方便，或者提升代碼品質，避免一些錯誤。如果是，就用，如果僅僅帶來了複雜，並沒有益處，那還是算了。

一句話，沒有該不該用，也沒有哪些需要不需要用，用就要帶來效益，無論是對團隊還是產品品質或產品的可維護性。用不用，要以團隊配合和產品為導向，這才是對一個軟體設計師的基本要求。

工廠的職能就是你給它一個模型或者具體的樣品需求，它給你一個成品。原廠模式也是這樣的道理，比如，你入參是a，它就給你一個A對象，你入參b，它就給你生產一個B對象，這裡a,b就是你讓工廠生產的商品具體需求，如長寬高等。

原廠模式還是很常見的，你沒用到可能是因為項目規模小，或者是類不夠抽象。

工廠你可以理解為隱藏了內部細節，你調用工廠的生產API ，直接獲得所描述的物體，具體怎麼生產的，你不用去關注細節，因為有的東西簡單，直接new出來就可以了，但有的很複雜，比如spring的注入鏈。要理解原廠模式，建議看看spring實現的factory。

