在设计模式中关于工厂模式有一点特殊,就标准意义而言我们一般提到的工厂模式一般包括三种:
❝「其实简单工厂不属于设计模式,由于它的使用场景还是比较多的,因此本篇将会一起介绍一下~」❞
工厂模式属于对象创建型模式,无论是上述三种的哪一种都是为了同一个设计原则即依赖抽象,不要依赖具体
简单来说就是把复杂对象创建(初始化)的细节或者依赖关系经常可能发生变化的细节交给一个第三方类(工厂类),避免在业务逻辑中书写不必要的内容
简单工厂在实际应用中非常的频繁,假设我们现在需要生产Intel和AMD相关的产品,来看看代码
public class SimpleFactory {
public static AbstractCPU createCpu (String type) {
switch (type) {
case "INTEL":
return new IntelCpu();
default:
return new AMDCpu();
}
/* if ("INTEL".equals(type)) {
return new IntelCpu();
} else if ("AMD".equals(type)){
return new AMDCpu();
}
return null;*/
}
}
❝「此种方式适合非常单一的场景,快速构建工厂代码,不用过多的思考」 ❞
值得注意的是静态方法和普通方法的区别,静态工厂让它不具备继承性,在某些场合可能导致无法扩展的问题,在代码优化层面可以配合枚举,Map等方式继续让代码变得更清爽一些
定义一个用于创建对象的接口,让子类决定实例化哪一个类,Factory Mehod使一个类的实例化延迟到其子类
工厂方法用来处理对象的创建,并将这样的行为封装在子类中,这样,客户程序中关于超类的代码就和子类对象创建代码解耦了。
咱们还是一样,说说人话:
【产品】:最近我们有英特尔和AMD的CPU产品订购方案,您看能不能实现一下相关的代码?
【BOSS】:它们的装配啊,生产啊等等的细节一样吗?
【产品】:嗯嗯,细节流程都是一样的!
【BOSS】:那个谁,小柯啊,工厂方法模式懂吗,去做吧,给你半天时间,好好设计设计。
【开发】:好的!(内心OS:我不会啊!!!)
不会的话,只能看书学习啦~
「父级接口」
public abstract class Factory {
/***
* 产品订购方案
*/
public AbstractCPU orderCpu () {
AbstractCPU cpu = generateCpu();
cpu.show();
cpu.prepare();
cpu.box();
// 假设有相同的业务处理逻辑...
return cpu;
}
protected abstract AbstractCPU generateCpu();
}
「具体实现」
public class IntelCpuFactory extends Factory {
@Override
public AbstractCPU generateCpu() {
return new IntelCpu();
}
}
// ****************************************************************
public class AMDCpuFactory extends Factory {
@Override
public AbstractCPU generateCpu() {
return new AMDCpu();
}
}
工厂方法模式的设计思路:
在下列情况下可以使用 Factory Method模式:
例如在工厂生产电池时,对于电池的保管,订货,输送的方式可能完全一致,但是仅型号不一致,因此分别交给A流水线,B流水线进行生产,但是后续的其他流程又是重合的
提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类
PS:故事内容承接工厂方法模式的诞生~
【产品】:我... 我好像搞错需求了...
【BOSS】:什么意思???
【产品】:咱们的订单不是仅仅只生成CPU产品,而是要生成英特尔还有AMD的全系列产品...
【BOSS】:你你你你... 之前的功夫都白费了啊!
【产品】:不就是生产东西嘛,反正都是生产,我不管,你要给我实现!
【BOSS】:小柯,委屈你了。
【开发】:好吧,那我能问一个问题吗?未来是不是还有可能要生产华为的,联想的?
【产品】:对!很有可能!如果我们生意做大了!
抽象工厂模式着重点在产品族上,开始撸代码吧~
「父级抽象类」
public abstract class AbstractFactory {
/**
* 创建CPU对象
* @return CPU对象
*/
public abstract AbstractCPU createCpu();
/**
* 创建主板对象
* @return 主板对象
*/
public abstract AbstractMotherboard createMainboard();
}
「子类实现」
public class IntelFactory extends AbstractFactory{
@Override
public AbstractCPU createCpu() {
return new IntelCpu();
}
@Override
public AbstractMotherboard createMainboard() {
return new IntelMotherboard();
}
}
// *************************************************************
public class AMDFactory extends AbstractFactory{
@Override
public AbstractCPU createCpu() {
return new AMDCpu();
}
@Override
public AbstractMotherboard createMainboard() {
return new AMDMotherboard();
}
}
抽象工厂模式的设计思路:
思路示意图:
没错,抽象工厂的方法经常以工厂方法的方式实现,因为抽象工厂的任务通常是定义一个负责创建一组产品的接口,在这个接口内的每个方法都负责创建一个具体的产品,「而这种某一个具体的产品的实质就是工厂方法模式的实践」
在以下情况可以使用 Abstract Factory 模式:
比如上述的情况,观察代码我们可以发现我们其实是把一个产品族进行了封装,如果这个时候要引入华为系列产品,我们完全不用动任何代码,只需要增加一个类即可,非常符合开闭原则
「依赖抽象,而不是依赖具体」
「相同点:」
「工厂方法:」
「抽象工厂:」
GitHub地址:https://github.com/kkzhilu/Kerwin-DesignPattern