? ? ? 菜鳥D在項目中遇見一個比較糾結(jié)的高耦合，所以就想辦法來解耦。情況是這樣的：系統(tǒng)通過用戶選擇treeview控件的節(jié)點判斷調(diào)用不同的處理，這些處理中某些東西又是類似的。同事的建議是采用簡單工廠，耦合就耦合吧，反正treeview節(jié)點基本是不會變化的。（能偷懶就偷懶吧）

? ? ? 菜鳥D有些偏執(zhí)，想找些方法來解耦。于是就學(xué)習(xí)了這個幾種方法，雖然不一定用的上，多學(xué)一點總是好的。

? ? ? 首先說簡單工廠，例子是一個已經(jīng)二到死的計算器。

? ? ? 簡單工廠由三種角色組成：工廠類角色（creator），抽象產(chǎn)品類角色（product,圖中為Iproduct接口），具體產(chǎn)品類角色（concreteproduct,圖中為Product_A…）。

? ? 代碼如下：

public class Calculate{public double DValue1 { get; set; }public double DValue2 { get; set; }public virtual double GetResult(){return 0;}}public class Add : Calculate{public override double GetResult(){return DValue1 + DValue2;}}public class Sub : Calculate{public override double GetResult(){return DValue1 - DValue2;}}public class Mul : Calculate{public override double GetResult(){return DValue1 * DValue2;}}public class Div : Calculate{public override double GetResult(){if (DValue2.Equals(0)){if (DValue1.Equals(0)){return 1;}return 0;}return DValue1 / DValue2;}} 基本的代碼 #region 客戶端Console.WriteLine("請輸入第一個數(shù)");string v1 = Console.ReadLine();Console.WriteLine("請輸入運(yùn)算符");string oper = Console.ReadLine();Console.WriteLine("請輸入第二個數(shù)");string v2 = Console.ReadLine();Calculate c = GetCalculateByOper(oper);c.DValue1 = Convert.ToDouble(v1);c.DValue2 = Convert.ToDouble(v2);Console.WriteLine("結(jié)果：" + c.GetResult()); #endregion#region 工廠方法private static Calculate GetCalculateByOper(string oper){Calculate c = new Calculate();switch (oper){case "+": c = new Add();break;case "-": c = new Sub();break;case "*": c = new Mul();break;case "/": c = new Div();break;}return c;} #endregion

? ? ? 在這個例子中沒有使用抽象類，接口，而是用了虛方法（純粹是不想在接口里定義屬性，自己喜歡用什么就用什么，畢竟這不是簡單工廠的核心）。簡單工廠的核心是充當(dāng)工廠類角色的工廠方法（起碼在此例中是這樣），邏輯判斷中使具體產(chǎn)品類和工廠直接耦合了（好像類圖的關(guān)系已經(jīng)決定了這種耦合，但是將具體產(chǎn)品和客戶端解耦）。如果要添加一個開方運(yùn)算，首先添加開方的運(yùn)算類，然后打開工廠方法進(jìn)行修改。（呵呵，違反了開閉原則）

? ? ?接下來再說一下工廠方法模式，類圖如下：

? ? ? 先分析一下類圖，工廠模式有了四個角色：工廠接口，工廠實現(xiàn)，產(chǎn)品接口，產(chǎn)品實現(xiàn)（其實說角色不貼切，還不如說是種類）。工廠實現(xiàn)和產(chǎn)品實現(xiàn)有了依賴關(guān)系，通過調(diào)用工廠實現(xiàn)來獲取產(chǎn)品實現(xiàn)。也就是一種產(chǎn)品實現(xiàn)對應(yīng)一種工廠實現(xiàn)。

? ? ?還是那個二的要死的計算器的例子，代碼如下：

public interface IFactory{ICalculatable GetCalculatable();}public interface ICalculatable{double GetReslut(double d1, double d2);}public class Add : ICalculatable{public double GetReslut(double d1, double d2){return d1 + d2;}}public class AddFactory : IFactory{public ICalculatable GetCalculatable(){return new Add();}}public class Sub : ICalculatable{public double GetReslut(double d1, double d2){return d1 - d2;}}public class SubFactory : IFactory{public ICalculatable GetCalculatable(){return new Sub();}}public class Mul : ICalculatable{public double GetReslut(double d1, double d2){return d1 * d2;}}public class MulFactory : IFactory{public ICalculatable GetCalculatable(){return new Mul();}}public class Div : ICalculatable{public double GetReslut(double d1, double d2){if (d2.Equals(0)){if (d1.Equals(0)){return 1;}return 0;}return d1 / d2;}}public class DivFactory : IFactory{public ICalculatable GetCalculatable(){return new Div();}} 基本代碼 #region 邏輯判斷public class Factory{public static IFactory GetCalculatableByOper(string oper){IFactory factory = null;switch (oper){case "+": factory = new AddFactory();break;case "-": factory = new SubFactory();break;case "*": factory = new MulFactory();break;case "/": factory = new DivFactory();break;}return factory == null ? null : factory;}} #endregion#region 客戶端Console.WriteLine("請輸入第一個數(shù)");string v1 = Console.ReadLine();Console.WriteLine("請輸入運(yùn)算符");string oper = Console.ReadLine();Console.WriteLine("請輸入第二個數(shù)");string v2 = Console.ReadLine();ICalculatable calculatable = Factory.GetCalculatableByOper(oper).GetCalculatable();Console.WriteLine("結(jié)果：" + calculatable.GetReslut(Convert.ToDouble(v1), Convert.ToDouble(v2))); #endregion

? ? ? 注意：此處的判斷邏輯已經(jīng)不屬于工廠模式了（類圖中很明確），也可以脫離客戶端。雖說簡單工廠也可以這樣將判斷邏輯脫離客戶端，但是簡單工廠的邏輯判斷是在工廠類中的，也就依然是簡單工廠模式的一部分（此處邏輯有些亂，不懂的就認(rèn)真研究類圖）。通常在工廠模式的客戶端需要用到哪種工廠再去創(chuàng)建哪種工廠，而不是如例子中的使用一個判斷邏輯來選擇，也就是工廠模式創(chuàng)建工廠是通過“外部”的邏輯來確定，而模式本身是不會做判斷的。（所以這個例子并不是一個合適的例子）

? ? ? 此時，計算器要再添加一個開方的方法，只需添加方法實現(xiàn)，添加工廠實現(xiàn)，不會對原有的代碼做修改，符合了開閉原則（你當(dāng)我瞎啊，你不修改判斷邏輯嗎？說了多少次了，判斷邏輯部分不屬于工廠模式。不過比簡單工廠確實多寫不少東西）。

? ? ? 工廠方法模式通常在以下兩種情況中使用 :

? ? ? 第一，需要使用某種產(chǎn)品,客戶端很清楚應(yīng)該使用哪個具體工廠，此種情況不存在上述的判斷邏輯，只需要實例化具體工廠，然后生產(chǎn)具體產(chǎn)品。

? ? ? 第二，需要使用某種產(chǎn)品，但是不想也不需要知道是哪個工廠創(chuàng)建，此種情況存在一定的判斷邏輯，但是客戶端不需要知道這個邏輯，生產(chǎn)方（工廠模式）是通過外部的邏輯來生產(chǎn)產(chǎn)品，這時由外部來實例化具體工廠，生產(chǎn)具體產(chǎn)品交付給客戶端。

? ? ? 接著再來說說抽象工廠，在抽象工廠中最明顯的一個特點是產(chǎn)品不止一類了，所以前文提到的計算機(jī)的例子就不適合使用抽象工廠模式（竊以為如此，有反對意見的歡迎提出）。

? ? ? 在抽象工廠在提到一個“產(chǎn)品族”的概念，其實在抽象工廠中最為直觀的體現(xiàn)就是產(chǎn)品A接口，產(chǎn)品B接口甚至是產(chǎn)品C、D接口。類圖如下，從類圖中不難發(fā)現(xiàn)，抽象工廠模式的具體工廠角色可以生產(chǎn)多種產(chǎn)品（工廠方法模式的具體工廠只能生產(chǎn)一種產(chǎn)品，不信去看類圖）。就好像東方紅拖拉機(jī)廠在工廠方法模式下只能生產(chǎn)拖拉機(jī)，但是在抽象工廠模式下不僅能生產(chǎn)拖拉機(jī)，還能生產(chǎn)卡車（如果加一個坦克的生產(chǎn)線，還能生產(chǎn)坦克）。

? ? ? 此處就用比較熟悉的農(nóng)場的例子，農(nóng)場生產(chǎn)水果和蔬菜，水果分為北方水果和熱帶水果，蔬菜也一樣，所以農(nóng)場也分為北方農(nóng)場和熱帶農(nóng)場。

? ? ? 代碼如下：

public interface IFruit{string Show();}public interface IVeggie{string Show();}public class NFruit : IFruit{private string name;public string Name{get { return "北方" + name; }set { name = value; }}public string Show(){return Name;}}public class TFruit : IFruit{string name;public string Name{get { return "熱帶" + name; }set { name = value; }}public string Show(){return Name;}}public class NVeggie : IVeggie{string name;public string Name{get { return "北方" + name; }set { name = value; }}public string Show(){return Name;}}public class TVeggie : IVeggie{string name;public string Name{get { return "熱帶" + name; }set { name = value; }}public string Show(){return Name;}}public interface Factory{IFruit CreateFruit(string nm);IVeggie CreateVeggie(string nm);}public class NFactory : Factory{public IFruit CreateFruit(string nm){return new NFruit() { Name = nm };}public IVeggie CreateVeggie(string nm){return new NVeggie() { Name = nm };}}public class TFactory : Factory{public IFruit CreateFruit(string nm){return new TFruit() { Name = nm };}public IVeggie CreateVeggie(string nm){return new TVeggie() { Name = nm };}} 基本代碼

? ? ? 此例的邏輯判斷部分沒寫。從類圖上看，它是不屬于抽象工廠模式的，從簡化客戶端的角度，這個邏輯判斷是可以從客戶端剝離的，很顯然和工廠方法模式的邏輯判斷屬于同一地位（有種兩頭受氣的感覺）。

? ? ?然后再簡單說spring的依賴注入。在spring中需要獲取一個產(chǎn)品（實例）如何獲取？容器來提供。邏輯判斷呢？可以放在客戶端，也可以從客戶端剝離，愛放哪放哪。容器只依賴于配置，邏輯判斷不會影響容器。所以容器很好的將生產(chǎn)過程與客戶端隔離，這就不存在耦合了。

? ? ? 接下來再說一下，一直不停的重復(fù)的判斷邏輯。在菜鳥D 的看法里，上述幾個模式的耦合都是存在于判斷邏輯中的。在簡單工廠中，工廠和客戶端之間耦合較低，但是工廠和具體的產(chǎn)品類是直接耦合的。在工廠方法模式、抽象工廠模式、spring中，邏輯判斷只是一個輔助，邏輯判斷將生產(chǎn)過程和客戶端隔離，大大地降低了耦合程度。所以在衡量設(shè)計模式的耦合時，就需要衡量判斷邏輯在模式中作用和角色。有些耦合是很難避免的，為了避免這些耦合甚至可能會造成更多的耦合。至于開閉原則，編碼過程盡量去注意，否則為以后的開發(fā)帶來麻煩就不是我們想要的了。

? ? ?一家之言，不值一哂，如有謬誤，歡迎指正。

? ? ?菜鳥D希望這篇文章對您有所幫助。

擴(kuò)展參考：

大話設(shè)計模式P72:

? ? ? 工廠方法實現(xiàn)時,客戶端需要決定實例化哪一個工廠來實現(xiàn)運(yùn)算類(具體產(chǎn)品),選擇判斷的問題還是存在的,也就是說,工廠方法吧簡單工廠的內(nèi)部邏輯判斷移到了客戶端代碼來進(jìn)行.想要添加功能,本來是要改工廠類的,而現(xiàn)在是修改客戶端.

三種工廠模式區(qū)別總結(jié)

http://blog.csdn.net/lingfengtengfei/article/details/12374469

spring.net的依賴注入

http://www.cnblogs.com/GoodHelper/archive/2009/10/26/SpringNET_DI.html

工廠方法模式

http://blog.csdn.net/zhengzhb/article/details/7348707

三種工廠模式

http://www.cnblogs.com/poissonnotes/archive/2010/12/01/1893871.html

?

轉(zhuǎn)載于:https://www.cnblogs.com/cnDqf/p/4122771.html

總結(jié)

以上是生活随笔為你收集整理的简单工厂模式,工厂方法模式,抽象工厂模式,spring的狂想的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。