我一直在阅读Head First: Design Patterns这本书,我发现这本书是对设计模式的一个很好的介绍。但是,我对第4章中提出的声明提出了疑问:
他们定义了"简单工厂"模式如下(Java伪代码):
public abstract class Product
{
// Product characteristics
// Concrete Products should subclass this
}
public class SimpleFactory {
public Product createProduct(){
// Return an instance of some subclass of Product
}
}
public class Store {
SimpleFactory factory;
public Product orderProduct(){
Product product = factory.createProduct();
// Do some manipulation on product
return product;
}
}
"工厂方法"定义如下(类Product保持不变并省略):
public abstract class Store {
//Concrete Stores must subclass this and override createProduct()
public abstract Product createProduct();
public Product orderProduct(){
Product product = createProduct();
// Do some manipulation on product
return product;
}
}
然后作者继续声称工厂方法模式比简单工厂灵活得多,因为虽然简单工厂是一次性交易,但是使用工厂方法创建一个框架,让子类决定应该使用哪种实施方式" (第135页)。
现在我不知道为什么这是真的。从我看来,Simple Factory在某种意义上比工厂方法略微更多灵活:您可以将Simple Factory子类化(而不是子类化Store)以获得基本相同的行为。如果您愿意,甚至可以在运行时更改行为!我想到的Simple Factory的唯一缺点是产品创建依赖于Store类的状态变量:这是作者所说的灵活性,还是我错过了什么?
答案 0 :(得分:3)
你是绝对正确的:作者的假设是你不会继承SimpleFactory
,这不是一个公平的假设(除非SimpleFactory
被标记{{1} })。
由于final
不是最终的,所以你肯定可以对它进行子类化,比使用工厂方法获得更多的灵活性,因为SimpleFactory
用组合替换了继承。
更好的方法是使SimpleFactory
成为一个界面。这样做可以让你根据自己的喜好选择组合或继承,因为在SimpleFactory
类已经继承了类的情况下,接口不会限制你。
Store
然后你可以使用任何一种成分
public interface SimpleFactory {
Product createProduct();
}
或继承/组合组合
public class FactoryImpl implements SimpleFactory {
public Product createProduct(){
// Return an instance of some subclass of Product
}
}
public class StoreComposition {
SimpleFactory factory = new FactoryImpl();
}
答案 1 :(得分:0)
在Simple Factory中,您编写了一个类,该类提供了非常强大的封装,但是只做一件事:封装对象的创建和基础类型。虽然Factory Method模式充分利用了此类的优点:它完成了Simple Factory的工作,此外,它还封装了创建过程,不仅可以创建“原始新对象”,而且还可以交付/功能齐全的结果,这就是为什么它调用orderProduct
而不只是createProduct
的原因。
简而言之,工厂方法的要点是使用简单工厂的方法。因此,如果您认为Factory Method不那么灵活,那是因为Factory Method可以做更多的事情!