strategy模式

     上半年做过一个计费系统，大体介绍下需求：

      具体涉及到多个其他系统，产品线，订单系统，产品配置中心，计费中心

      产品线订购产品，产生一份合同(order),订单上存在计费策略(billingStrategyId)，计费系统保存一份合同COPY，以及根据计费策略到产品配置中心获取计算价格所需要的各种纬度（譬如本月使用量，计费根据本月小于100是1元，大于是0.8元），计费围绕合同产生，产品线用户使用一次产品，会发送一份使用记录到计费系统，计费系统统计计算价格所需要的各种纬度信息，并根据统计信息和使用记录计算价格。

      抛开其他系统之间的交互，单看计费系统我们从模型上看有以下四种模型

 

   

 

         用户体系：其实计费系统标志一个使用者。

         订单镜像：产品端在使用是不会关注使用者的合同信息，他只知道userId+product,订单镜像更可以理解为计费策略提供者。

         统计信息：计费所需要参数，记录各种纬度统计信息，根据策略按需记录；

         产品：在最初的设计中并没有产品的概念，其实从业务逻辑上看，消费记录--》找到订单镜像--》统计信息--》计算价格也可行；为何单独将其独立成模型呢？

         1.订单是有状态实体，而产品是无状态的（针对计费系统）。

         2.从模型上看，计价并不是根据合同，而是根据消费记录和产品。

 

         ok,来看看策略模式：定义了算法包，让彼此可以相互替换，让算法与使用的客户解耦。

     针对产品线到计费批价这块逻辑，我们看下

 

        Product:计费产品

              Map<String,IChargeParamsBuildService>：为需要统计的各种纬度MAP，KEY为统计纬度，IChargeParamsBuildService 为对应的统计算法。

             IChargeService：对应的计价算法；

            chargeStrategyId：对应的计价策略；

            productCode：产品名称；

 

        如下具体处理的时序图：

 

 

 

附件有源代码，直接导入可以运行test里的MAIN方法