近期整合静态工厂、工厂方法和抽象工厂模式。
在介绍工厂方法模式(3.3)时,我对工厂方法模式的合理情景/最佳实践,花了一点时间。
@H_404_7@
虽然从技术的角度,上面说明了从静态工厂方法到工厂方法模式的演变(这一过程对使用工厂方法模式充满误导),但是在God的例子中使用工厂方法模式,如果不采用参数传递的话,会出现如下的代码:
public staticfinal Locator locator = new MapLocatorFactory().getLocator();
这是非常典型的“为了模式而模式”的应用,与locator= new MapLocator()相比较,没有明显的好处。换言之,当God依赖Locator,出于初始化Locator的目的使用工厂方法模式,是不能令人信服的。
使用工厂方法模式的合理情景/最佳实践,我称之为依赖丈母娘原则。
★依赖丈母娘原则,Client依赖丈母娘,而丈母娘正好有一个工厂方法。 @H_404_7@例如Client开车ICar,不管什么车Client都可以开,初始化ICar使用工具类God或依赖注入容器,而ICar有问题则需要其4S店处理,正好ICar有一个抽象方法
public I4S get4S(); @H_404_7@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实现类的同名方法(参考简单代理模式)。
@H_404_7@ 注意到:《Head First 设计模式》在这里介绍了DIP,并给出的解答是“倒置你的思考方式”,所以:
依赖丈母娘原则 = (Head First 设计模式).DIP@H_404_7@
读了一下《HeadFirst 设计模式·4工厂模式》,一个字评价烂,两个字,超级烂。
抽象类Pizza的代码忽略,它有一系列子类型如CheesePizza等; 而SimplePizzaFactory很容易理解,注意通常SimplePizzaFactory的工厂方法设计成静态的(没有理由让它为实例方法)。
从最终的用户PizzaTestDrive出发,假设它很关心披萨/Pizza,则其main中只需要代码:SimplePizzaFactory.createPizza("cheese");
《HeadFirst 设计模式》的该例程,使用了一点技巧:从一开始就考虑 披萨店/PizzaStore依赖Pizza。但是即便如此,出于为PizzaStore初始化Pizza的目的,而使用工厂方法模式,仍然是难以令人信服的。 @H_404_7@package init.factory; public class PizzaStore {// public final Pizza orderPizza(String type) { Pizza pizza= SimplePizzaFactory.createPizza(type); pizza.foo();//由此,我们假设PizzaTestDrive不直接调用SimplePizzaFactory return pizza; } }@H_404_7@
按照依赖丈母娘原则,正确的设计是PizzaTestDrive依赖披萨店/PizzaStore而PizzaStore正好作为Pizza的工厂。换言之,只有PizzaStore是Pizza的工厂才合理。
为了使得PizzaStore成为Pizza的工厂,作者开始说胡话了。在《加盟披萨店》中,。"现在我们考虑更多加盟店的需求:他们需要他们自己风格的口味,但是加盟店的一些业务流程又必须严格按照总店进行处理"。《我们已经有一个做法……》中,你的NYPizzaFactory等3个类和SimplePizzaFactory是什么关系?(类型爆炸);到《给披萨店使用的框架》,不管该作者说了些什么,总之目的就是使PizzaStore成为丈母娘。
你介绍工厂模式就介绍工厂模式,你要明确地说orderPizza(String type)是 模板方法也可以,《允许子类做决定》写得超烂。最最讨厌的是Pizza是地域与风味的叉乘,如果有10个城市,5种风味,Pizza需要50个子类。 @H_404_7@后面的懒得看了,,