一、概述在軟件系統中，經常面臨着“某個對象”的創建工作，由於需求的變化，這個對象的具體實現經常面臨着劇烈的變化，但是它卻擁有比較穩定的接口。如何應對這種變化？如何提供一種封裝機制來隔離出“這個易變對象”的變化，從而保持系統中“其它依賴該對象的對象”不隨着需求的改變而改變？這就可以用到工廠方法模式 ...

一、引言 在上一篇文章中我們講解了過渡的一種模式叫做【簡單工廠】，也有叫【靜態工廠】的，通過對簡單工廠模式得了解，我們也發現了它的缺點，就是隨着需求的變化我們要不停地修改工廠里面的方法的代碼，需求變化越多，里面的If--Else--也越多，這樣就會造成簡單工廠的實現邏輯過於復雜 ...

問題：簡單工廠模式比較適用於事先已經考慮到的可能出現的算法，來構造工廠類實現，如果需要添加新的類，則就需要改變工廠類了，違反開閉原則，簡單的說，簡單公共適應與業務變化不是很劇烈的場景下如，審批業務，設計時可以判斷到的只有“部門經理審批”，“總裁審批”不會過幾天又要加入“組長審批”，去修改工廠類 ...

工廠方法模式概述 工廠方法模式是為了彌補簡單工廠模式的不足並且繼承它的優點而延生出的一種設計模式，屬於GoF中的一種。它能更好的符合開閉原則的要求。 定義：定義了一個用於創建對象的接口，但是讓子類決定將哪一個類實例化。即讓類的實例化延遲到子類 舉個例子：大眾汽車 ...

返回目錄 在簡單工廠的講解中，出現了很多問題，我們對象統一行為抽象出一個接口（或者抽象類）之后，再根據你傳入的類型進行創建實例，這只適合於你有固定行為的場合，當你要實現接口的類型處於不定數時，則不適合使用簡單工廠模式，而應該用工廠方法了。 適用場合： 子類有統一的操作行為 子類的數量不固定 ...

工廠方法模式（Factory Method） 工廠模式適合：凡是出現了大量的產品需要創建，並且具有共同的接口時，可以通過工廠方法模式進行創建。在以下的三種模式中，第一種如果傳入的字符串有誤，不能正確創建對象，第三種相對於第二種，不需要實例化工廠類，所以，大多數情況下，我們會選用第三種——靜態工廠方法 ...

在簡單工廠模式中通過工廠Factory獲取不同的對象，但是有一個明顯的缺點——簡單工廠模式系統難以擴展！ 一旦添加新產品就不得不修改簡單工廠方法，這樣就會造成簡單工廠的實現邏輯過於復雜， 可以通過工廠方法模式可以解決簡單工廠模式中存在的這個問題，看代碼： 汽車類下面有兩種 ...

本文源自深入淺出設計模式. 只不過我是使用C#/.NET Core實現的例子. 前言 當你看見new這個關鍵字的時候, 就應該想到它是具體的實現. 這就是一個具體的類, 為了更靈活, 我們應該使用的是接口(interface). 有時候, 你可能會寫出這樣的代碼: 這里有 ...