设计模式与泡mm的关系之工厂模式及工厂模式的再思考

 

我跑我跑我跑，J

 

网上的原文是这样子的：

1、抽象FACTORY，追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说"来四个鸡翅"就行了。麦当劳和肯德基就是生产鸡翅的Factory

抽象工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，

带着MM到服务员那儿，说"要一个汉堡"，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

 

点评：

       从比较简单的Factory Method开始说。FM的定义是：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。根据定义，在模式中应该有如下几个接口和类：

Interface iCreator：创建对象的接口

Class cCreator: 创建对象的具体类，继承自iCreator

Interface iProduct: 产品接口类

Class cProduct: 具体产品类，具体要被实现的类，继承自iProduct

按照上面的描述：我是client，mm是cCreator，汉堡是iProduct，具体汉堡是cProduct。什么是iCreator呢？我的理解是我带的mm，比如说我可以带mm甲来，我也可以带mm乙来吃汉堡的。不同的mm有不同的口味，那么不同口味的汉堡就是cProduct了。这个理解还是蛮match的，看来pass了，呵呵。

 

上面的Abstract Factory，AF的定义是：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。根据类的定义，我觉得上面的描述还是有点问题的。根据上面的描述，它认为肯德基与麦当劳是Factory。它们怎么可能是Factory呢？他们应该是concrete product！我觉得一个正确的理解是这样子的：mm们都喜欢吃鸡翅和鸡腿（mm们真能吃噢），不同的mm喜欢的可能不一样，比如说mm甲喜欢K的鸡翅和K的鸡腿，mm乙则喜欢K的鸡翅和M的鸡腿，mm丙则喜欢M的鸡翅和M的鸡腿。所以说，这个时候，creator应该是我带来的mm（今天我带好多mm来噢，哈哈）。cCreator就是mm甲或乙了。那么Factory应该是mm们。而鸡翅和鸡腿则是iProductWing和iProductLeg，肯德基的鸡翅和鸡腿则是cProductWing和cProductLeg，麦当劳的也是一样的。