工厂方法模式如何解决简单工作方法中的不足？

看《Java与模式》时，发现一个理解上的问题：说工厂方法模式可能解决简单工厂方法的不足，不过我的理解是工厂方法模式把原来的问题抛给客户端而没有真正解决掉。

 

先看简单工厂模式的示例代码。

 

class Factory{
	static Product createProduct(String type) {
		if(type.equalsIgnoreCase("apple")) {
			return new AppleProduct();
		}else if(type.equalsIgnoreCase("grape")) {
			return new GrapeProduct();
		}else {
			throw new IllegalArgumentException("Not type corresponding");
		}
	}
}

class Client_SimpleFactoryMethod {
	public static void main(String[] args) {
		String type = "grape";
		
		Product p = Factory.createProduct(type);
	}
}

interface Product{}

class AppleProduct implements Product{}
class GrapeProduct implements Product{}

 

它的缺点是如果有新产品时，Factory类中createProduct方法应该做相应调整以包含新产品类的加入。哪新加了产品类BananaProduct，我们得给createProduct方法新加一个分支：

   else if(type.equalsIgnoreCase("banana")) {

return new BananaProduct();

}

  这样不好， 因为这样的处理违背了“开闭”原则。

 

  为了解决这个问题，书中说引入工厂方法模式就可以了。 

 

  于是新加了每个产品类对应的工厂

interface ProduectFactory{
	Product createProduct();
}


class AppleProduectFactory implements ProduectFactory{

	public Product createProduct() {
		
		return new AppleProduct();
	}
}
class GrapeProduectFactory implements ProduectFactory{
	public Product createProduct() {
		
		return new GrapeProduct();
	}
}


class Client_FactoryMethod {
	public static void main(String[] args) {
		String type = "grape";
		
		ProduectFactory produectFactory=null;
		
		if(type.equalsIgnoreCase("apple")) {
			produectFactory = new AppleProduectFactory();
		}else if(type.equalsIgnoreCase("grape")) {
			produectFactory = new GrapeProduectFactory();
		}
			
		Product p = produectFactory.createProduct();
	}
}

 

对比上面的简单工厂方法，所不同的是，上面Client_SimpleFactoryMethod里的p的生成，是由Factory类的createProduct方法来据type种类判断具体生成哪种Product（直接生成）;而在Client_FactoryMethod中的main里，先据type生成一个

ProduectFactory实现，再由这个ProduectFactory生成一个具体的Product。

 

 

问题是， 新产品BananaProduct引入时，工厂这边新加一个BananaProductFactory没问题，而客户端得加一个相应的判断分支。看来不厚道啊，相当于把问题推给客户端。

 

 

我知道，上面我的理解有偏差的地方，工厂模式的价值不会这个“偏差”而有所降低，请问理解的偏差在哪？

评论

5 楼 Sasori 2011-08-01  

我觉得工厂模式的意图是把工厂具体方法的实现与客户端对工厂的使用解耦，而不是动态的生成不同的工厂。

4 楼 rmn190 2010-07-12  

factoryClass = System.getProperty(BusFactory.BUS_FACTORY_PROPERTY_NAME);

这样可以减少形如
        if(type.equalsIgnoreCase("apple")) { 
            produectFactory = new AppleProduectFactory(); 
        }else if(type.equalsIgnoreCase("grape")) { 
            produectFactory = new GrapeProduectFactory(); 
        } 
这样的if-else判断。

从而达到调用与实现的解耦合。

当然有些比这个getProperty更深一点的配置。 如Java\jdk1.6.0_18\jre\lib\security\java.security文件中“security.provider.1=sun.security.provider.Sun”类似property的配置。

3 楼 rmn190 2010-07-06  

引用

是抽象工厂

谢谢二位的回复。


不过我觉得有个问题，你说那是“抽象工厂”， 我不认为是， 抽象工厂的价值是“生产”出相关的一组产品，表现在代码上也就是一个接口（或抽象类）中有多个生成方法。这里的ProduectFactory接口只有一个方法， 也就不存在“相关”产品的说法了。


在闫宏所写的《Java与模式》一书中的第153页中有相关的例子代码“Creator”， 可参考。

2 楼 opmic 2010-07-06  

确实是抽象工厂

1 楼 键盘寄生物 2010-07-06  

其实 你这个不是工厂方法模式吧， 是抽象工厂。

个人理解,
在这里， 抽象工厂模式并不是用来简化判断分支的代码的，因为只有客户端知道什么时候该用哪段程序，
所以，这个判段代码不论是在客户端代码，还是在工厂里都是必须的。只能考虑通过配置，反射等方式来解决这个问题。


这里引入抽象工厂的主要目的

首要的 是用来将不同判断分支的代码分离，使方法轻量化。

第一你可以想象如果每个分支的代码段有上百行，如果全部写在一个方法里， 那是多么的臃肿，而不易阅读。

第二如果分支达到数十个，那这个方法体不仅臃肿，而且难以修改，阅读。

所以分离各个分支到单独的类是将工厂方法轻量化的可行办法。


其次  用来解耦工厂方法业务，提供扩展性。

考虑如下这个问题： 如果其中某个分支的代码不满足业务要求，需要替换怎么办？
如果将分支都写在工厂方法里，那将导致代码的修改，
第一，这个方法也许很臃肿，修改难度大。第二，如果又想恢复之前的业务，之前的代码由于修改丢失了，现在想恢复，只能再次修改代码了，扩展性极差。

如果使用抽象工厂模式，则只需增加新的业务工厂类。在修改客户端代码 就能实现了。同时不会造成原工厂的丢失修改。如果使用SPRING之类的注入方式，则连客户端都无需修改，只要改配置文件就行了。
具有良好的扩展性和低侵入性，符合 开、闭原则。

因此这里使用抽象工厂模式是正确的。