简单工厂模式
简单工厂模式不是23种里的一种,简而言之,就是有一个专门生产某个产品的类。
比如下图中的鼠标工厂,专业生产鼠标,给参数0,生产戴尔鼠标,给参数1,生产惠普鼠标。
示例代码:
//一个产品接口 只有一个产品接口,说明是一类产品 public interface ProductA{ }; //产品类 实现相同的产品接口 相同类型的不同产品 public class ProductA1 implements ProductA{ } public class ProductA2 implements ProductA{ } //一个工厂类 由它来调用不同的产品类生产以上的产品 public class Factory { public static ProductA create(String productName) throws Exception{ if(productName.equals("ProductA1")){ return new ProductA1(); }else if(productName.equals("ProductA2")){ return new ProductA2(); }else{ throw new Exception("没有该产品"); } } } //有了这个工厂类,我们就可以开始下定单了,SimpleFactory将根据不同的定单类决定生产什么产品。 public static void main(String[] args) { try { Factory.create("ProductA1"); Factory.create("ProductA2"); Factory.create("ProductA3"); } catch (Exception e) { e.printStackTrace(); } }
简单工厂的核心就是一个SimpleFactory类,他拥有必要的逻辑判断能力和所有产品的创建权利,我们只需要向把定单给他,就能得到我们想要的产品。这使用起来似乎非常方便。
但,实际上,这个SimpleFactory有很多的局限。
首先,我们每次想要增加一种新产品的时候,都必须修改SimpleFactory的原代码。违背了开放--封闭原则。
其次,当我们拥有很多很多产品的时候,而且产品之间又存在复杂的层次关系的时候,这个类必须拥有复杂的逻辑判断能力,其代码量也将不断地激增,这对以后的维护简直就是恐怖两个字...
还有就是,整个系统都严重依赖SimpleFactory类,只要SimpleFactory类一出问题,系统就进入不能工作的状态,这也是最为致命的一点....
以上的不足将在工厂模式的另外两种状态中得到解决。
工厂方法模式
定义一个用于创建对象的接口,让子类决定实例化哪个类。工厂方法使一个类的实例化延迟到其子类。
工厂模式也就是鼠标工厂是个父类,有生产鼠标这个接口。
戴尔鼠标工厂,惠普鼠标工厂继承它,可以分别生产戴尔鼠标,惠普鼠标。
生产哪种鼠标不再由参数决定,而是创建鼠标工厂时,由戴尔鼠标工厂创建。
后续直接调用鼠标工厂.生产鼠标()即可
示例代码:
//一个产品接口 只有一个产品接口,说明是一类产品 public interface ProductA{ }; //实现相同的产品接口 相同类型的不同产品 public class ProductA1 implements ProductA{ } public class ProductA2 implements ProductA{ }
//工厂接口 public interface Factory{ public ProductA create(); } //多个产品工厂 public class ProductA1Factory implements Factory{ public ProductA create(){ return new ProductA1(); } } public class ProductA2Factory implements Factory{ public ProductA create(){ return new ProductA2(); } }
从上面创建产品对象的代码可以看出,工厂方法和简单工厂的主要区别是,简单工厂是把创建产品的职能都放在一个类里面,而工厂方法则把不同的产品放在实现了工厂接口的不同工厂类里面,这样就算其中一个工厂类出了问题,其他工厂类也能正常工作,互相不受影响,以后增加新产品,也只需要新增一个实现工厂接口的工厂类,就能达到,不用修改已有的代码。但工厂方法也有他局限的地方,那就是当面对的产品有复杂的等级结构的时候,例如,工厂除了生产家电外产品,还生产手机产品,这样一来家电、手机就是两大产品家族了,这两大家族下面包含了数量众多的产品,每个产品又有多个型号,这样就形成了一个复杂的产品树了。如果用工厂方法来设计这个产品家族系统,就必须为每个型号的产品创建一个对应的工厂类,当有数百种甚至上千种产品的时候,也必须要有对应的上百成千个工厂类,这就出现了传说的类爆炸,对于以后的维护来说,简直就是一场灾难.....
抽象工厂模式
抽象工厂模式也就是不仅生产鼠标,同时生产键盘。
也就是PC厂商是个父类,有生产鼠标,生产键盘两个接口。
戴尔工厂,惠普工厂继承它,可以分别生产戴尔鼠标+戴尔键盘,和惠普鼠标+惠普键盘。
创建工厂时,由戴尔工厂创建。
后续工厂.生产鼠标()则生产戴尔鼠标,工厂.生产键盘()则生产戴尔键盘。
在抽象工厂模式中,假设我们需要增加一个工厂
假设我们增加华硕工厂,则我们需要增加华硕工厂,和戴尔工厂一样,继承PC厂商。
之后创建华硕鼠标,继承鼠标类。创建华硕键盘,继承键盘类。
即可。
在抽象工厂模式中,假设我们需要增加一个产品
假设我们增加耳麦这个产品,则首先我们需要增加耳麦这个父类,再加上戴尔耳麦,惠普耳麦这两个子类。
之后在PC厂商这个父类中,增加生产耳麦的接口。最后在戴尔工厂,惠普工厂这两个类中,分别实现生产戴尔耳麦,惠普耳麦的功能。
以上。
工厂方法用来创建一个产品,它没有分类的概念,而抽象工厂则用于创建一系列产品,所以产品分类成了抽象工厂的重点,
示例代码:
图与代码的对应关系
PcFactory --> Factory
HpFactory --> Factory1
DellFactory --> Factory2
Mouse --> ProductA
HpMouse --> ProdectA1
DellMouse -- ProductA2
Keybo --> ProductB
HpKeybo --> ProdectB1
DellKeybo -- ProductB2
// 有多个产品接口,多种类型产品 public interface ProductA{ }; public interface ProductB{ }; //多种类型产品(A、B) 每种产品底下还有分类 A1 A2 B1 B2 public class ProductA1 implements ProductA{ } public class ProductA2 implements ProductA{ } public class ProductB1 implements ProductA{ } public class ProductA2 implements ProductA{ } //工厂接口 public interface Factory{ public ProductA createProductA(); public ProductB createProductB(); } //不同的工厂 每个工厂都创建一系列产品 public class Factory1 implements Factory{ //创建A类产品 public ProductA1 createProductA1(){ return new ProductA1(); } //创建B类产品 public ProductB1 createProductB1(){ return new ProductB1(); } } public class Factory2 implements Factory{ //创建A类产品 public ProductA2 createProductA2(){ return new ProductA2(); } //创建B类产品 public ProductB2 createProductB2(){ return new ProductB2(); } }
ps总结:
1 简单工厂模式:只有一个产品接口(一种产品) 一个工厂类,根据给定的参数返回对应产品的实例
2 工厂模式: 只有一个产品接口(一种产品) 多个工厂类,各自返回各自的产品实例 相比于简单工厂模式的好处:一个工厂类的情况下,工厂类瘫痪,所有产品都生产不了,多个工厂类情况下,一个工厂类挂掉,不影响其他产品的生产
3 抽象工厂模式: 多个产品接口(重在产品分类) 多个工厂类,每个工厂类都要创建所有产品的实例 相比于工厂模式,抽象工厂则用于创建一系列产品,所以产品分类成了抽象工厂的重点
参考
http://www.cnblogs.com/zhouqiang/archive/2012/07/20/2601365.html