依赖丈母娘原则

近期整合静态工厂、工厂方法和抽象工厂模式。

在介绍工厂方法模式（3.3）时，我对工厂方法模式的合理情景/最佳实践，花了一点时间。

虽然从技术的角度，上面说明了从静态工厂方法到工厂方法模式的演变(这一过程对使用工厂方法模式充满误导)，但是在God的例子中使用工厂方法模式，如果不采用参数传递的话，会出现如下的代码：

public staticfinal Locator locator = new MapLocatorFactory().getLocator();

这是非常典型的“为了模式而模式”的应用，与locator= new MapLocator()相比较，没有明显的好处。换言之，当God依赖Locator，出于初始化Locator的目的使用工厂方法模式，是不能令人信服的。

使用工厂方法模式的合理情景/最佳实践，我称之为依赖丈母娘原则。

★依赖丈母娘原则，Client依赖丈母娘，而丈母娘正好有一个工厂方法。

例如Client开车ICar，不管什么车Client都可以开，初始化ICar使用工具类God或依赖注入容器，而ICar有问题则需要其4S店处理，正好ICar有一个抽象方法

public I4S get4S();

public class Client{
    public static void main(String[] args) {
		ICar car =(ICar)God.create("Car"); //ICar car =new BBCar();
		car.move();
		I4S repair = car.get4S();
		repair.doSomething();
		car.move();
	}
}

换言之，Client关注和依赖的，是工厂ICar，而工厂的产品I4S ，Client可以一无所知。需要的时候，ICar可以设计一个doSomething()，其中调用对应I4S实现类的同名方法（参考简单代理模式）。

注意到：《Head First 设计模式》在这里介绍了DIP，并给出的解答是“倒置你的思考方式”，所以：

依赖丈母娘原则 = （Head First 设计模式）.DIP

读了一下《HeadFirst 设计模式·4工厂模式》，一个字评价烂，两个字，超级烂。

抽象类Pizza的代码忽略，它有一系列子类型如CheesePizza等；而SimplePizzaFactory很容易理解，注意通常SimplePizzaFactory的工厂方法设计成静态的(没有理由让它为实例方法)。

从最终的用户PizzaTestDrive出发，假设它很关心披萨/Pizza，则其main中只需要代码：SimplePizzaFactory.createPizza("cheese");

《HeadFirst 设计模式》的该例程，使用了一点技巧：从一开始就考虑披萨店/PizzaStore依赖Pizza。但是即便如此，出于为PizzaStore初始化Pizza的目的，而使用工厂方法模式，仍然是难以令人信服的。

package init.factory;
public class PizzaStore {//    
    public final Pizza orderPizza(String type) {
        Pizza pizza= SimplePizzaFactory.createPizza(type);
        pizza.foo();//由此，我们假设PizzaTestDrive不直接调用SimplePizzaFactory
        return pizza;
    }
}

按照依赖丈母娘原则，正确的设计是PizzaTestDrive依赖披萨店/PizzaStore而PizzaStore正好作为Pizza的工厂。换言之，只有PizzaStore是Pizza的工厂才合理。

为了使得PizzaStore成为Pizza的工厂，作者开始说胡话了。在《加盟披萨店》中，。"现在我们考虑更多加盟店的需求：他们需要他们自己风格的口味，但是加盟店的一些业务流程又必须严格按照总店进行处理"。《我们已经有一个做法……》中，你的NYPizzaFactory等3个类和SimplePizzaFactory是什么关系？（类型爆炸）；到《给披萨店使用的框架》，不管该作者说了些什么，总之目的就是使PizzaStore成为丈母娘。

你介绍工厂模式就介绍工厂模式，你要明确地说orderPizza(String type)是 模板方法也可以，《允许子类做决定》写得超烂。最最讨厌的是Pizza是地域与风味的叉乘，如果有10个城市，5种风味，Pizza需要50个子类。

后面的懒得看了，，

猜你喜欢