为了提升自身编写代码的风格规约,打算学一学恼人的设计模式,今天从工厂设计模式开始~
工厂模式属于创建型设计模式,也是比较常用的设计模式之一,从字面意思,我们就可以知道它是用来创建对象的一个工厂,那么我们何时去选择使用这一设计模式呢?
设计思想
我们通过创建一个接口,让其实现类根据相应的条件有选择的创建对象,而不对外暴露出具体创建过程,外部只知道调用了接口,而不知道对象是如何创建的。
例子
从上面我们可以知道,这样的结构使代码之间的耦合度降低,提高了代码的可重用性,方便测试、修改和扩展,举个例子:
在一个电商项目,物流系统包括了航空物流、陆上物流和海上物流,在不同情况下需要根据需要调用不同的物流方式
项目结构为
——src
——main
——java
——com.xxx.demo.logis
——service
——impl
——AviationLogisticsServiceImpl
——MarineLogisticsServiceImpl
——OnshoreLogisticsServiceImpl
——LogisticsService
——logisticsFactory
——test
——java
... ...
首先创建一个接口LogisticsService,要想创建3种物流方式,都需要通过这个接口来处理。
public interface LogisticsService {
void getLogistic(各种参数);
}
接下来创建实现接口的实体类AviationLogisticsServiceImpl、MarineLogisticsServiceImpl、OnshoreLogisticsServiceImpl。这些类中需要实现具体的业务,你可以看到,每个实现类互不干扰,这对未来业务的维护很友善,若将来想添加新的物流方式,例如“无人机物流”,那么只需要按照相似的结构编写业务逻辑即可。
public class AviationLogisticsServiceImpl implements LogisticsService {
@Override
public void getLogistic(各种参数) {
具体业务逻辑...
}
}
public class OnshoreLogisticsServiceImpl implements LogisticsService {
@Override
public void getLogistic(各种参数) {
具体业务逻辑...
}
}
public class MarineLogisticsServiceImpl implements LogisticsService {
@Override
public void getLogistic(各种参数) {
具体业务逻辑...
}
}
最后创建一个工厂Factory,生成基于给定信息的实体类对象。这里的给定信息,我们假设当传入的参数Lcode为10301时,生成航空物流;参数为10302时,生成海上物流,参数为10303时,生成陆上物流。
public class logisticsFactory {
//使用 getLogis 方法获取物流类型的对象
public LogisticsService getLogis(String Lcode){
if(Lcode == null){
return null;
}
if(Lcode.equals("10301")) return new AviationLogisticsServiceImpl();
if(Lcode.equals("10302")) return new MarineLogisticsServiceImpl();
if(Lcode.equals("10303")) return new OnshoreLogisticsServiceImpl();
throw new RuntimeException("此物流方式不存在")
}
}
在工厂中,你可以根据相应的条件来创建对象,若以后增加了新的物流,可以到这里进行修改。
总结:
在工厂模式中,每个实体类都只关心自己的业务逻辑,都只有一个功能,这满足了单一职责原则,同时调用者在创建对象时无需了解具体创建流程,避免了与业务逻辑发生碰撞,最后,工厂模式的扩展性好,但不宜加入过多的“产品”。