簡單工廠模式（不屬于23種設計模式）
參考博文：https://zhuanlan.zhihu.com/p/390926587，
模式定義：
定義一個工廠類，可以根據提供的不同引數，回傳不同的實體，并且被創建的實體通常具有共同的父類，
uml類如如下：
簡單來說，product是個一個抽象產品介面，ConcreteProduct類實作了具體的介面方法，而Factory類通過傳入不同引數，
生成不同的ConcreteProduct類，而通過多型的方式使用product方法，
優點：通過使用工廠類，外部可以免于直接創建具體物件的職責和邏輯，而直接使用物件，（明確了各自的職責和權力），
缺點：工廠類集中了所有產品的創建邏輯，職責過重，一旦例外，整個系統將受影響；并且隨著具體產品類數量增加，會引發邏輯復雜和擴展困難，
適用場景：工廠類負責創建對的物件比較少；客戶端只知道傳入工廠類的引數，對如何創建物件不關心
一些框架涉及的原始碼分析：
nacos：
在Nacos的client中，存在NamingFactory（注冊）、ConfigFactory（配置）、NamingMaintainFactory（注冊中心）,每個都是一個獨立的工廠類，分別生產不同的實體，
然而，另外還有NacosFactory的工廠類，該類統一提供了創建ConfigService（配置中心服務）、NamingService（注冊中心服務）和NamingMaintainService（注冊中心實體操作服務）
的實體化方法（多載），
初次看到這部分的原始碼的時候我很疑惑，搞不懂這樣設計的意義何在，想要創建任何一個實體物件，直接呼叫當前實體物件的工廠方法就可以了，給它多加一層簡單工廠模式的意義何在呢？
在參考了其他博主的文章后，我總結應該是為了聚合，
首先：是為了把nacos相關的實體集中對外提供，用戶想要創建呼叫實體只需直接關聯使用一個類，
另外：因為nacos的業務只需提供三種不同的實體，也符合簡單工廠模式的使用準則，
個人總結（不一定正確）
結合個人的專案經驗中，如果對于同一個程式入口，接收同樣格式/型別的資料，業務場景處理邏輯不一樣，并且不同業務場景個數不會太多，并且有可能之后還會有新的操作，可以考慮使用簡單工廠模式，
假設對外提供一個資料同步介面，根據提交的引數不同分別回傳3+種型別的資料，可以先定義一個同步介面類，里面存在抽象的業務處理方法，定義3+個類實作介面類，最后再定義一個工廠類，通過傳入的引數不同，創建不同實體，再通過多型的方法呼叫不同實體的具體實作方法，這樣實作，即使以后需要新增同步資料的總類，也不會改動原來的代碼，只需要新建實作類，降低了耦合，便于維護，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/308468.html
標籤：其他
上一篇：負載均衡在web系統中的應用
下一篇：菜鳥架構師之路開篇