关于java:设计模式工厂方法以及SpringBoot注入整合附实例

39次阅读

共计 5415 个字符,预计需要花费 14 分钟才能阅读完成。

平时咱们在工作开发过程中,往往因为工期问题导致整体功能设计思考的不够周到,导致前期迭代时发现须要原有性能流程根底上追加新性能时,须要消耗更多的老本,无奈轻易颠覆重构,接着便是一误再误,在 if else 之下再来一层 elseif。所以好代码构造,往往时我的项目教训积攒进去的,会了不代表能,只有实际了、实现了,有理论价值体现了,能力发现学习是一点点积攒提高的过程。

而设计模式自身就是通过有数我的项目积攒积淀而来,适宜什么形式什么计划去设计实现性能,往往须要全局的剖析,思考到整体,以及将来的可扩展性等等。

1、场景剖析

工作中其实有很多性能是能够应用设计模式的,通过设计模式去优化代码,达到代码的复用性,缩小耦合,也就是咱们常说的高内聚低耦合。

场景 1:商城下单

事件是这样的,小陈接到领导的工作调配,告知要为负责的商城我的项目实现下单功能,于是小陈是胸有成竹的实现了,因为工夫问题,小陈并没有对性能花工夫去做过多设计。便有了以下代码:

@Override
 @Transactional(rollbackFor = ServiceException.class)
 public String createBuyOrders(BuyOrders buyOrders, List<String> couponIds, Long integral, Long integralGym)throws ServiceException{productBll.updateSkuStockAndSaleNumber(buyOrders.getBuyOrderProductId(), buyOrders.getBuyOrderSkuId(), buyOrders.getBuyOrderQuantity());
 // 订单根底信息
 creatOrderBase(buyOrders);
 // 计算订单价格
 normalCalculationOrderPrice(buyOrders);
// 欠缺地址信息
 setOrderAddress(buyOrders);
 // 调用优惠券
 couponBll.useCoupons(buyOrders.getBuyOrderUserId(),buyOrders,couponIds);
 if(!IIntegralInfoBll.buyUseIngegral(buyOrders, integral, integralGym)){throw new ServiceException("积分扣除失败,请从新下单");
 }
 if (FavoritesHelper.isNotNull(IBuyOrdersDao.insertBuyOrders(buyOrders))){
 // 创立订单敞开订单工作
 if (FavoritesHelper.isNotEmpty(systemVariable)){closeTime = systemVariable.getSystemVariableVale();
 }
 quartzService.orderTimeout(buyOrders.getBuyOrderNo(),ISystemVariableBll.ORDER_TIME_OVER);
 return buyOrders.getBuyOrderNo();}
 throw new RuntimeExcaption("订单创立失败");

过了几周甲方提出了需要,想要实现拼多多那种团购性能,然而因为有优惠了,所以局部优惠券无奈应用。小陈感觉没什么压力,于是对新增了一种订单类型:团购订单:public String createBuyOrders(BuyOrders buyOrders, List<String> couponIds, Long integral, Long integralGym)throws ServiceException{if(buyOrders.getType == 1){// 失常订单;参考上一段代码} else if(buyOrders.getType == 2){
 // 团购订单;具体性能脑部
 // 大略实现点:满足设置多少人成为一个团,加入多久人没齐会主动勾销,拼团过程中有人退出解决,胜利解决,订单生成未领取锁定解决
 } else{throw new RuntimeException("谬误的订单类型");
 }
}

至此,小陈感觉没啥压力,也就一个办法几百行代码,小问题。

又过了几周,甲方新需要,要有一个秒杀和商品预售性能,小陈顿感压力,还是硬着头皮上了,不就是多几个 if else 吗,还就没有我小陈 ifelseif 实现不了的性能了,如果有,就再来一次 else if。

于是乎 …:

public String createBuyOrders(BuyOrders buyOrders, List<String> couponIds, Long integral, Long integralGym)throws ServiceException{if(buyOrders.getType == 1){// 失常订单;参考上一段代码} else if(buyOrders.getType == 2){
 // 团购订单;具体性能脑补
 // 大略实现点:满足设置多少人成为一个团,加入多久人没齐会主动勾销,拼团过程中有人退出解决,胜利解决,订单生成未领取锁定解决
 }  else if(buyOrders.getType == 3){
 // 秒杀订单;具体性能脑补
 // 大略实现点:满足条件商品进行秒杀抢购,流量消峰、库存管制、订单生成
 }  else if(buyOrders.getType == 4){
 // 商品预售订单;具体性能脑补
 // 大略实现点:定价收缩,尾款领取揭示
 } else{throw new RuntimeException("谬误的订单类型");
 }
}

没等小陈接到甲方的下一个需要,小陈因为可能是集体起因辞职了,于是新来的阿彬承受了小陈的代码,碰巧甲方来了新需要:我想来个周期购,减少我商城的复购率 …balabala…

于是阿彬关上先辈的代码一看,好家伙,绝了!这货色我怎么 … 还没有正文 …

2、开始重构

其实向上述的业务情景还有很多,比方与其绝对于的商品新增。例如商品填写完根底信息之后须要满足商品的周期购售卖逻辑,须要绝对于的商品配置逻辑;绝对的团购也是,预售商品更为简单。咱们能够一开始就对这些性能进行正当的布局,而后找出了优化(简化)的点。就算优化不了,也可将整体的代码进行正当的设计,不至于保护起来破费太多的老本。

下单从新实现:

// 1 首先:定义下单接口
public interface ICreateOrderBll {
​
    void createOrder(BuyOrders orders);
​
}
​
// 2 其次:实现下单接口
//2.1 秒杀
public class KillSaleOrderBllImpl implements ICreateOrderBll {
     @Override
     public void createOrder(BuyOrders orders) {​}
}
​
//2.2 一般订单
public class NormalOrderBllImpl implements ICreateOrderBll {
     @Override
     public void createOrder(BuyOrders orders) {​}
}
​
// 3 预售订单
public class PreSaleOrderBllImpl implements ICreateOrderBll {
     @Override
     public void createOrder(BuyOrders orders) {​}
}
​
// 4 团购订单
public class GroupSaleOrderBllImpl implements ICreateOrderBll {
     @Override
     public void createOrder(BuyOrders orders) {​}
}
​
// 5 创立工厂办法的工厂
public class BuyOrderFactory {
​
     public ICreateOrderBll getOrderBll(OrderTypeEnum orderType) throws RuntimeException{if (ObjectHelper.isEmpty(orderType)) return null;
     else if (orderType.equals(OrderTypeEnum.NORMAL_ORDER)) return new NormalOrderBllImpl();
     else if (orderType.equals(OrderTypeEnum.KILL_SALE)) return new KillSaleOrderBllImpl();
     else if (orderType.equals(OrderTypeEnum.PRE_SALE)) return new PreSaleOrderBllImpl();
     else if (orderType.equals(OrderTypeEnum.GROUP_SALE)) return new GroupSaleOrderBllImpl();
     else throw new RuntimeException("不存在的订单类型");
     }
    ​
}
// 6 备注:其中 OrderTypeEnum 是定义的订单类型枚举类
​
// 7 调用
public void createNewOrder(){BuyOrders killSaleOrder = new BuyOrders();
    ​
     BuyOrderFactory factory = new BuyOrderFactory();
    ​
     ICreateOrderBll killSaleService = factory.getOrderBll(OrderTypeEnum.KILL_SALE);
     killSaleService.createOrder(killSaleOrder);// 秒杀业务
    ​
     BuyOrders preSaleOrder = new BuyOrders();
     ICreateOrderBll preSaleService = factory.getOrderBll(OrderTypeEnum.PRE_SALE);
     preSaleService.createOrder(preSaleOrder);// 预售
​
}

自此,下单就重构实现(具体实现依据要求来)。

3、整合 SpringBoot

小陈通过学习理解了工厂办法,懂得了其中的些许神秘,可是奈何我的项目是 SpringBoot,只学了皮毛的小陈照虎画猫, 去发现实现的代码,在代码执行到具体的业务实现层却发现空指针,不对啊,不是传进来的对象都有收到啊,怎么没会空指针呢,商品也失常获取啊,怎么回事呢?

通过 debug,小陈发现是所写的代码没有胜利注入 SpringBoot 中,是对象间接报空指针,所以调用办法是抛出了异样。

于是,小陈悟了:

// 重点圈圈 1
@Component
public class BuyOrderFactory {
​
     // 重点圈圈 2
     @Resource
     private Map<OrderTypeEnum,ICreateOrderBll> handlerMap;
    ​
     public ICreateOrderBll getOrderBll(OrderTypeEnum orderType) throws RuntimeException{if (ObjectHelper.isEmpty(orderType)) return null;
     else if (orderType.equals(OrderTypeEnum.NORMAL_ORDER)) return new NormalOrderBllImpl();
     else if (orderType.equals(OrderTypeEnum.KILL_SALE)) return new KillSaleOrderBllImpl();
     else if (orderType.equals(OrderTypeEnum.PRE_SALE)) return new PreSaleOrderBllImpl();
     else if (orderType.equals(OrderTypeEnum.GROUP_SALE)) return new GroupSaleOrderBllImpl();
     else throw new RuntimeException("不存在的订单类型");
     }
​
}
​
// 调用
 // 重点圈圈 3
 @Resource
 BuyOrderFactory factory;
 
 public void createNewOrder(){BuyOrders killSaleOrder = new BuyOrders();
    ​
     ICreateOrderBll killSaleService = factory.getOrderBll(OrderTypeEnum.KILL_SALE);
     killSaleService.createOrder(killSaleOrder);// 秒杀业务
    ​
     BuyOrders preSaleOrder = new BuyOrders();
     ICreateOrderBll preSaleService = factory.getOrderBll(OrderTypeEnum.PRE_SALE);
     preSaleService.createOrder(preSaleOrder);// 预售
​
 }

再起初,小陈由此开始了设计模式学习的不归路。

正文完
 0