We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
1 parent 598772a commit 1b23786Copy full SHA for 1b23786
1 file changed
DesignPatterns/Factory/README.md
@@ -32,3 +32,30 @@
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
0 commit comments