《Head First 设计模式·4工厂模式》评价

近期整合静态工厂、工厂方法和抽象工厂模式。因为我很厌恶DIP，所以仔细看了一下《Head First 设计模式·4工厂模式》。

一个字评价烂，两个字，超级烂。

这本书的行文风格，各有喜好，我不评价——虽然我不喜欢花里胡哨的插图等。我们看其内容。

不应该用new，这节没有问题。《识别变化的方面》给出一个很烂的例子。PizzaStore与Pizza。抽象类Pizza有一系列子类型如CheesePizza等等；PizzaStore要依赖抽象类Pizza，因此将创建Pizza对象的工作交给SimplePizzaFactory很容易理解。有一点要注意，通常SimplePizzaFactory的工厂方法设计成静态的(没有理由让它为实例方法，该书似乎准备为工厂方法模式做准备，所以搞成实例方法)。

为什么说这是很烂的例子？PizzaStore->Pizza，可以用Client-IServer关系加以一般化，可以随便地举例，如人依赖抽象类“交通工具”。现在PizzaStore->Pizza关系问题不大。关键在后面。

《加盟比萨店》开始，就难于理解了。在本节中，"现在我们考虑更多加盟店的需求：他们需要他们自己风格的口味，但是加盟店的一些业务流程又必须严格按照总店进行处理"。

我首先想到的是，Pizza的子类型成为地域与风味的叉乘，如果有2个城市，4种风味，Pizza需要8个子类。（类型爆炸）

而《我们已经有一个做法...》，以SimplePizzaFactory为父类，有了三个参数化工厂NYPizzaFactory等。这样也可以。

《但是你想要多一些质量控制...》开始显得奇怪了。你讲对象的创建，为什么要提到模板方法模式和框架？好像作者为了把PizzaStore设计成工厂，在胡乱地找借口。也就是说，因为PizzaStore有一个模板方法定义了制作比萨店流程，所以把PizzaStore设计成工厂。（前面PizzaStore与Pizza中间，加了SimplePizzaFactory。现在又胡乱地找借口，想把PizzaStore设计成工厂）。

package init.factory;
public abstract class PizzaStore {//    
    public final Pizza orderPizza(String type) {
        Pizza pizza= createPizza(type);
        pizza.foo();//制作流程
        return pizza;
    }
    abstract Pizza createPizza(String type);
}

 

不知道作者从什么角度考虑，要在《给披萨店使用的框架》中讨论框架。反正，后面他就顺着写，没有什么好说的，一直到令人作呕的DIP。他对DIP的解释，倒是比DIP的提出者正确——要依赖抽象（类型），不要依赖具体类。既然依赖倒置错误百出，那么《Head First 设计模式》对倒置了什么的解释，再怎么奇葩都可以理解——《倒置你的思考方式》。后面的懒得看了，，

为什么说这是很烂的例子？如果人->“交通工具”。交通工具有子类汽车、单车，那么交通工具和修理厂的关系，很容易说明交通工具和修理厂要一一对应，交通工具将作为修理厂的工厂。汽车修理厂修理汽车....而在PizzaStore->Pizza例子中，正好相反，相当于修理厂->交通工具(PizzaStore->Pizza),而交通工具按照价位可以分成高中低挡（Pizza有地域风格），于是作者把修理厂作为工厂，有高档修理厂(纽约PizzaStore)等子类型，而高档修理厂可以修理高档汽车和高档单车。正因为不自然，作者在这里提到模板方法模式、框架和DIP。

总之，我个人觉得《Head First 设计模式·4工厂模式》写得没有一点水平，超级稀烂。

从结果看，正确的设计的确是PizzaTestDrive依赖披萨店/PizzaStore而PizzaStore正好作为Pizza的工厂，因为NYPizzaStore生产NY风格的比萨。正如我说的，工厂方法模式要解决类型匹配问题。