你說對業務上沒有用到這個可以理解，還有不要認為只有類名稱為Factory的才是工廠，比如UUID對象，目前有4種版本UUID，都不是new實例化的，通過一個Factory產出各種版本的UUID，通常這樣設計的原因是為了解決大量同接口類別的創建問題，經過分組抽象後，方便進行統一管理，類似的還有encoding charset

幹了那麼多年還是沒遇到那就很悲劇了，首先可以考慮跳槽換家大公司你就會遇到了。
工廠模式最簡單的就是關係型/非關係型資料庫切換，版本切換，類別庫切換。等等，你沒遇到的原因是因為不需要後期維護或根本不用考慮版本迭代，資料庫更新吧？

其他的設計模式也是各有各的作用，這東西你沒遇到感覺不重要，遇到了就會感覺這東西太好用了，十分巧妙的運用了類的封裝，繼承，多態。

再者，程式設計師進步就是研究框架源碼，語言源碼，大並發，代碼可維護性。

就舉個jdk的例子， Executors類別它有個newFixedThreadPool的靜態方法，介面定義如下：

public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) {

可以看到，第二個參數是可以傳入一個執行緒工廠，然後Executors類別就可以根據工廠方法來建立線城池所需的執行緒。換句話說，就是你可以把你要創建線程的規則都寫在ThreadFactory中咯。比如說，讓該工廠創建的線程名字都為XXX-前綴、或者指定線程優先權等等。

這個可以說是工廠模式最常見的場景，在各個框架的應用比比皆是。學習設計模式，啃書之餘多看實際程式碼，自然才會發現模式具體作用，甚至是各種巧用的技巧。

不論是工廠模式還是其它創建型模式，都是一個目的－為了初始化一個物件。或者說，為了建構一個資料結構模型（類別和物件本身就是一種自訂的資料結構）。

那麼，問題來了，為什麼有new這樣可以建立一個對象，還要使用設計模式。本質上就是一個原因，不想讓上層使用者直接使用 new 來初始化物件。new这样方式可以创建一个对象，还要使用设计模式。本质上就是一个原因，不想让上层使用者直接使用 new 来初始化对象。

这样的原因有很多，绝大多数原因就是对上层的使用者隔离对象创建的过程；或者是对象创建的过程复杂，使用者不容易掌握；或者是对象创建要满足某种条件，这些条件是业务的需求也好，是系统约束也好，没有必要让上层使用者掌握，增加别人开发的难度。

所以，到这时我们应该清楚了，无论是工厂模式，还是上面的战友说的开闭原则，都是为了隔离一些复杂的过程，使得这些复杂的过程不向外暴露，如果暴露了这些过程，会对使用者增加麻烦，这也就是所谓的团队合作。

面向对象封装的本身也就是为了使得对外的API尽可能的简化。

例如，你定义了一个Status字段，但这个字段因为某些业务原因，需要使用整数来表示状态。那么，如果数字少了还好办，如果数字多了，上层使用者就不一定能记清楚每个数字代表的状态（比如你要做语音通信系统，那么，语音设备是有很多状态数字的）。这时，如果使用new来创建对象，然后再对Status

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

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

物件導向封裝的本身也就是為了使得對外的 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; } }

當然，使用枚舉也行，這個說穿了，就是看設計者的意願了。 所以，設計模式沒有說必需在哪個場景中使用，更確切的說，應該是，當你使用了設計模式，能不能為你的團隊成員帶來方便，或者提升代碼質量，避免一些錯誤。如果是，就用，如果只是帶來了複雜，並沒有益處，那還是算了。 一句話，沒有該不該用，也沒有哪些需要不需要用，用就要帶來效益，無論是對團隊還是產品品質或產品的可維護性。用不用，要以團隊配合和產品為導向，這才是對一個軟體設計師的基本要求。