平时咱们在工作开发过程中，往往因为工期问题导致整体功能设计思考的不够周到，导致前期迭代时发现须要原有性能流程根底上追加新性能时，须要消耗更多的老本，无奈轻易颠覆重构，接着便是一误再误，在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@Componentpublic 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);//预售 }再起初，小陈由此开始了设计模式学习的不归路。