1. 目的
—->工厂模式主要是为创建对象提供过渡接口,以便将创建对象的具体过程屏蔽隔离起来,达到提高灵活性的目的。
2. 分类
1)简单工厂模式(Simple Factory)
2)工厂方法模式(Factory Method)
3)抽象工厂模式(Abstract Factory)
3. 简单工厂模式
1.简单工厂模式又称为静态工厂方法模式。其目的为定义一个用于创建对象的接口。
2.组成:
—->1) 工厂类角色:这是本模式的核心,含有一定的商业逻辑和判断逻辑。
—->2) 抽象产品角色:它一般是具体产品继承的父类或者实现的接口。
—->3) 具体产品角色:工厂类所创建的对象就是此角色的实例。
3.具体例子:
—->在没有工厂模式之前,当我们需要一个产品的时候,通常是去创建一个产品。
/*
*一系列产品
*/
/*ProductOne*/
class ProductOne{
public ProductOne(){}
}
/*ProductTwo*/
class ProductTwo{
public ProductTwo(){}
}
/*客户*/
class Customer{
public ProductOne CreateProductOne(){
return new ProductOne();
}
public ProductTwo CreateProductTwo(){
return new ProductTwo();
}
}
—->有了简单工厂模式之后,把创建的操作细节都放到了工厂里面去,客户直接使用工厂的创建工厂方法,传入想要的产品就行了,而不必去知道创建的细节.这就是工业革命了:简单工厂模式。
/*
*产品类
*/
abstract class Product{}
/*ProductOne*/
class ProductOne : Product{
public ProductOne() { }
}
/*ProductTwo*/
class ProductTwo : Product{
public ProductTwo() { }
}
/*工厂*/
class Factory{
public static Product CreateProduct(string type){
switch (type){
case "ProductOne":
return new ProductOne();
case "ProductTwo":
return new ProductTwo();
default:
return null;
}
}
}
/*客户*/
class Customer{
public Product product;
public void GetProduct(string type){
this.product = Factory.CreateProduct(type);
}
}
—->这便是简单工厂模式了。怎么样,使用起来很简单吧?那么它带来了什么好处呢?首先,使用了简单工厂模式后,人们的程序不在“有病”,更加符合现实中的情况;而且客户端免除了直接创建产品对象的责任,而仅仅负责“消费”产品(正如暴发户所为)。下面我们从开闭原则(对扩展开放;对修改封闭)上来分析下简单工厂模式。当暴发户增加了一个产品的时候,只要符合抽象产品制定的合同,那么只要通知工厂类知道就可以被客户使用了。所以对产品部分来说,它是符合开闭原则的;但是工厂部分好像不太理想,因为每增加一个产品,都要在工厂类中增加相应的业务逻辑或者判断逻辑,这显然是违背开闭原则的。可想而知对于新产品的加入,工厂类是很被动的。对于这样的工厂类,我们称它为全能类或者上帝类。我们举的例子是最简单的情况,而在实际应用中,很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品,所以这可能会把我们的上帝累坏了,也累坏了我们这些程序员:( 于是工厂方法模式作为救世主出现了。
4.工厂方法模式
—->工厂方法模式去掉了简单工厂模式中工厂方法的静态属性,使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。
1)抽象工厂角色:这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。
2)具体工厂角色:它含有和具体业务逻辑有关的代码。
3)抽象产品角色:它是具体产品继承的父类或者是实现的接口。
4)具体产品角色:具体工厂角色所创建的对象就是此角色的实例。
工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说,这样便分担了对象承受的压力;而且这样使得结构变得灵活起来——当有新的产品产生时,只要按照抽象产品角色、抽象工厂角色提供的合同来生成,那么就可以被客户使用,而不必去修改任何已有的代码。可以看出工厂角色的结构也是符合开闭原则的!
/*
*产品类
*/
abstract class Product{
public Product() { }
}
/*ProductOne*/
class ProductOne : Product{
public ProductOne() { }
}
/*ProductTwo*/
class ProductTwo : Product{
public ProductTwo() { }
}
/*工厂类*/
abstract class Factory{
public virtual Product CreateProduct() { return null;}
}
/*FactoryOne*/
class FactoryOne{
public override ProductOne CreateProductOne(){
return new ProductOne();
}
}
/*FactoryTwo*/
class FactoryTwo{
public override ProductTwo CreateProductTwo(){
return new ProductTwo();
}
}
/*客户*/
class Customer{
private Product product;
public void GetProduct(string type){
switch (type){
case "ProductOne":
FactoryOne factoryOne = new FactoryOne();
this.product = factoryOne.CreateProductOne();
break;
case "ProductTwo":
FactoryTwo factoryTwo = new FactoryTwo();
this.product = factoryTwo.CreateProductTwo();
break;
default:
break;
}
}
}
—->可以看出工厂方法的加入,使得对象的数量成倍增长。当产品种类非常多时,会出现大量的与之对应的工厂对象,这不是我们所希望的。因为如果不能避免这种情况,可以考虑使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类:即对于产品树上类似的种类(一般是树的叶子中互为兄弟的)使用简单工厂模式来实现。
工厂方法模式仿佛已经很完美的对对象的创建进行了包装,使得客户程序中仅仅处理抽象产品角色提供的接口。那我们是否一定要在代码中遍布工厂呢?大可不必。也许在下面情况下你可以考虑使用工厂方法模式:
1) 当客户程序不需要知道要使用对象的创建过程。
2) 客户程序使用的对象存在变动的可能,或者根本就不知道使用哪一个具体的对象。
简单工厂模式与工厂方法模式真正的避免了代码的改动了?没有。在简单工厂模式中,新产品的加入要修改工厂角色中的判断语句;而在工厂方法模式中,要么将判断逻辑留在抽象工厂角色中,要么在客户程序中将具体工厂角色写死(就象上面的例子一样)。而且产品对象创建条件的改变必然会引起工厂角色的修改。
5.抽象工厂模式
—->先来认识下什么是产品族: 位于不同产品等级结构中,功能相关联的产品组成的家族。
—->可以说,抽象工厂模式和工厂方法模式的区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。
抽象工厂模式的用意为:给客户端提供一个接口,可以创建多个产品族中的产品对象而且使用抽象工厂模式还要满足一下条件:
1) 系统中有多个产品族,而系统一次只可能消费其中一族产品。
2) 同属于同一个产品族的产品以其使用。
来看看抽象工厂模式的各个角色(和工厂方法的如出一辙):
1) 抽象工厂角色: 这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
2) 具体工厂角色:它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。在java中它由具体的类来实现。
3) 抽象产品角色:它是具体产品继承的父类或者是实现的接口。在java 中一般有抽象类或者接口来实现。
4) 具体产品角色:具体工厂角色所创建的对象就是此角色的实例。在java 中由具体的类来实现。