1. 概述：
將一個具體類的實例化交給一個靜態工廠方法來執行，它不屬于gof的23種設計模式，但現實中卻經常會用到
2. 模式中的角色
2.1 工廠類（simple factory): 只包含了創建具體類的靜態方法。
2.2 抽象產品（product）：定義簡單工廠中要返回的產品。
2.3 具體產品（concreteproduct）：具體產品。
3. 模式解讀
3.1 簡單工廠模式的一般化類圖
3.2 簡單工廠模式的代碼實現
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
/// <summary>/// 簡單工廠類，用sealed修飾，/// </summary>public class simpleproductfactory{ /// <summary> /// 使用靜態方法，根據傳入的參數來指定要實例化哪一種產品 /// </summary> /// <param name="producttype"></param> /// <returns></returns> public static product createproduct(string producttype) { product product = null; switch (producttype) { case "a": product = new concreteproducta(); break; case "b": product = new concreteproductb(); break; } return product; }}/// <summary>/// 抽象產品/// </summary>public abstract class product{ public product() { } public abstract void opration();}/// <summary>/// 具體產品 a/// </summary>public class concreteproducta : product{ public concreteproducta() { } public override void opration() { // 產品a }}/// <summary>/// 具體產品 b/// </summary>public class concreteproductb : product{ public concreteproductb() { } public override void opration() { //產品b }} |
4. 模式總結
4.1 優點：
4.1.1 職責單一，實現簡單，且實現了客戶端代碼與具體實現的解耦。
4.1.2 工廠類是整個模式的關鍵.包含了必要的邏輯判斷,根據外界給定的信息,決定究竟應該創建哪個具體類的對象.
4.1.3 通過使用工廠類,外界可以從直接創建具體產品對象的尷尬局面擺脫出來,僅僅需要負責“消費”對象就可以了。而不必管這些對象究竟如何創建及如何組織的．
4.1.4 明確了各自的職責和權利，有利于整個軟件體系結構的優化。
4.2 缺點：
4.2.1 由于工廠類集中了所有實例的創建邏輯，違反了高內聚責任分配原則，將全部創建邏輯集中到了一個工廠類中；它所能創建的類只能是事先考慮到的，如果需要添加新的類，則就需要改變工廠類了。因此它是違背開放封閉原則的。
4.2.2 當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不同條件創建不同實例的需求．這種對條件的判斷和對具體產品類型的判斷交錯在一起，很難避免模塊功能的蔓延，對系統的維護和擴展非常不利；
注：這些缺點在工廠方法模式中得到了一定的克服。
4.3 使用場景：
4.3.1 工廠類負責創建的對象比較少；
4.3.2 客戶只知道傳入工廠類的參數，對于如何創建對象（邏輯）不關心；
4.3.3 由于簡單工廠很容易違反高內聚責任分配原則，因此一般只在很簡單的情況下應用。
以上就是本文的全部內容，希望能給大家一個參考，也希望大家多多支持服務器之家。
