思考工厂方法模式
工厂方法就是延迟到子类实现
例:一个Cpu抽象工厂,有多个子类,AmdCpu工厂、ItelCpu工厂等等,在子类中具体实现
1.工厂方法模式的本质
工厂方法模式的本质:延迟到子类来选择实现。
工厂方法模式中的工厂方法,在真正实现的时候,一般是先选择具体使用哪一个具体的产品实现对象,然后创建这个具体产品对象的示例,最后就可以返回去了。也就是说,工厂方法本身并不会去实现产品接口,具体的产品实现是已经写好了的,工厂方法只要去选择实现就好了。
有些朋友可能会说,这不是跟简单工厂一样吗?
从本质上讲,它们确实是非常类似的,在具体实现上都是“选择实现”。但是也存在不同点,简单工厂是直接在工厂类里面进行“选择实现”;而工厂方法会把这个工作延迟到子类来实现,工厂类里面使用工厂方法的地方是依赖于抽象而不是具体的实现,从而使得系统更加灵活,具有更好的可维护性和可扩展性。
2.何时选用工厂方法模式
建议在以下情况中选用工厂方法模式。
- 如果一个类需要创建某个接口的对象,但是又不知道具体的实现,这种情况可以选用工厂方法模式,把创建对象的工作延迟到子类中去实现。
- 如果一个类本身就希望由它的子类来创建所需的对象的时候,应该使用工厂方法模式。
3.优缺点
工厂方法模式的优点
-
可以在不知具体实现的情况下编程
工厂方法模式可以让你在实现功能的时候,如果需要某个产品对象,只需要使用产品的接口即可,而无需关心具体的实现。选择具体实现的任务延迟到子类去完成。 -
更容易扩展对象的新版本
工厂方法给子类提供了一个挂钩,使得扩展新的对象版本变得非常容易。比如上面示例的参数化工厂方法实现中,扩展一个新的导出 xml文件格式的实现,已有的代码都不会改变,只要新加入一个子类来提供新的工厂方法实现,然后在客户端使用这个新的子类即可。 -
连接平行的类层次
工厂方法除了创造产品对象外,在连接平行的类层次上也大显身手。这个在前面已经详细讲述了。
工厂方法模式的缺点
- 具体产品对象和工厂方法的耦合性。
在工厂方法模式中,工厂方法是需要创建产品对象的,也就是需要选择具体的产品对象,并创建它们的实例,因此具体产品对象和工厂方法是耦合的。
4.工厂方法模式的结构
- Product:定义工厂方法所创建的对象的接口,也就是实际需要使用的对象的接口。ConcreteProduct:具体的Product接口的实现对象。
- Creator:创建器,声明工厂方法,工厂方法通常会返回一个 Product类型的实例对象,而且多是抽象方法。也可以在Creator里面提供工厂方法的默认实现,让工厂方法返回一个缺省的Product类型的实例对象。
- ConcreteCreator:具体的创建器对象,覆盖实现 Creator定义的工厂方法,返回具体的Product实例。
5.实现
工厂类
/**
* @description:Cpu工厂
*/
public interface CPUFactory {
/**
* 创建cpu
* @return
*/
Cpu createCpu();
}
/**
* @description:Amd工厂
*/
public class AmdFactory implements CPUFactory {
@Override
public Cpu createCpu() {
return new AmdCpu(1157);
}
}
cpu产品
/**
* @description:cpu接口
*/
public interface Cpu {
/**
* 初始化cpu
*/
void initCpu();
}
/**
* @description:AMDcpu
*/
public class AmdCpu implements Cpu {
//针脚
private int pins=0;
public AmdCpu(int pins){
this.pins=pins;
}
@Override
public void initCpu() {
System.out.println("Cpu-->AMD 针脚数"+pins);
}
}
测试
public class Client {
public static void main(String[] args) {
CPUFactory factory=new AmdFactory();
factory.createCpu();
}
}