本文是在学习中的总结,欢迎转载但请注明出处:http://blog.csdn.net/pistolove/article/details/41142929
工厂方法模式定义了一个创建对象的接口,但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
从下面类图可以看出,抽象的创建者(Creator)提供了一个创建对象方法的接口,也称为“工厂方法”。其中,任何其它实现的方法,都可能使用该工厂方法制造出来的产品,但是只有子类真正实现这个工厂方法并创建产品。
其实,工厂方法是让子类决定要实例化的类是哪一个,但是这里的决定并不是说允许子类本身在运行时做决定,而是指在编写创建者(Creator)时,不需要知道实际创建的产品是哪一个,你选择的了使用哪个子类,那么自然就能决定实际创建的产品是什么。
当你直接地实例化一个类时,就是在依赖它的具体类。下面的类显示的是一个很依赖的面包店。
<span style="font-size:14px;">public class DependentBreadStore {
public Bread createBread(String style, String type) {
Bread Bread = null;
if (style.equals("NY")) {
if (type.equals("cheese")) {
Bread = new BJStyleCheeseBread();
} else if (type.equals("veggie")) {
Bread = new BJStyleVeggieBread();
} else if (type.equals("clam")) {
Bread = new BJStyleClamBread();
} else if (type.equals("pepperoni")) {
Bread = new BJStylePepperoniBread();
}
} else if (style.equals("Chicago")) {
if (type.equals("cheese")) {
Bread = new ChicagoStyleCheeseBread();
} else if (type.equals("veggie")) {
Bread = new ChicagoStyleVeggieBread();
} else if (type.equals("clam")) {
Bread = new ChicagoStyleClamBread();
} else if (type.equals("pepperoni")) {
Bread = new ChicagoStylePepperoniBread();
}
} else {
return null;
}
Bread.prepare();
Bread.bake();
Bread.cut();
Bread.box();
return Bread;
}
}</span>
这里我们就会联想到OO设计原则中一个很重要的原则:依赖倒置原则——要依赖抽象,而不要依赖具体类。其实,这个原则和“针对接口编程,不针对实现编程”。该
原则说明了:不能够让高层组件依赖于低层组件,而
且,不管是高层组件还是低层组件,“两者”都应该依赖于抽象。就像上面包店一样,BreadStore是“高层组件”,而面包的实现是“低层组件”,“两者”都应该依赖于抽
象,而BreadStore依赖于这些具体的类了。(所谓高层
组件,指的是由其它低层组件定义其行为的类。BreadStore是高层组件,其行为是由面包定义的:BreadStore创建所有不同的面包对象,进行一系列操作;而面包本
身属于低层组件。
避免在OO设计中违反依赖倒置原则主要有:
(1)变量不可持有具体类的引用。(如果使用New,就会持有具体类的引用)
(2)不要让类派生自具体类。(如果派生自具体类,你就会依赖具体类。请派生自抽象(接口或者抽象类))
(3)不要覆盖类中已实现的方法。(如果覆盖基类已实现的方法,那么你的基类就不是一个真正适合被继承的抽象。基类已实现的方法,应该由所有子类共享)
通过上面的分析,可知,运用工厂方法可以避免对象之间的依赖关系,从而使代码变得更加灵活。另外,我们也了解了OO设计原则中的依赖倒置原则,并知道以后在什么样的情况下使用该原则。
注意:依赖倒置原则并不是随时都要遵循的原则。也有违反这一指导方针的地方。比如,有一个不像是会改变的类,那么在代码中直接实例化具体类也就没有什么大
碍的了。想想平时我们在程序中不假思索地就实例化字符串对象了?就没有违反这个原则!因为字符串的不可变的。所以,针对不同的场景,我们需要对其进行分
析,从而能够灵活的运行各种原则,而不是一成不变的。