最近在重构公司的购物车，发现购物车里面商品有很多种活动。订单级、商品级活动，而且订单级活动里面包含单品级活动（比如：单品类满赠活动，里面某个商品还有单品直降活动）。
现在想用一种扩展性维护性都比较好的设计模式重新梳理一下代码，个位能给一些思路么？
filterchain类似这种的
正好最近在做一个项目 楼上说各种设计模式 呵呵 想太多了
我们的设计 复杂到什么程度
（1）常规打折
（2）批发价
（3）会员价
（4）单品优惠券减免
（5）全单优惠券减免
（6）满减满赠满折
（7）限时促销
（8）积分
....
最后的逻辑是触发任何一个修改就重新计算整个购物车的价格 而且你设计模式 这里面互斥多的很呢。。装饰器写着简单 你能互斥么 比如我会员价批发价打折3选1你怎么装饰器
ecshop的购物车写的够复杂了 我们这个比他还复杂 等等 你以为这就完了
如果用户没选活动怎么办
如果商品下架了怎么办
如果商品在车里突然价格变了或者活动结束了怎么办
tmd简直是个无底洞
所以 打死不在数据库里存价格 计算量大是小 算错钱了才是麻烦事
而且 就算你在数据库里存价格 后面一致性的问题写死你 还不如直接实时算
结账的时候肯定要所有数据校验一次 那还不如当初就不算
购物车我认为是没法简化的 设计模式不显示 上面说用插件的 用什么插件 所有的活动无外乎列出来的几种 你需要的是让使用者用你给的活动组合出需要的活动 尽可能简化设计
活动更多的不是叠加 而是互斥 所以装饰器不现实
如果你做N选1自动算最优惠更恶心 解决方案就是像京东 把活动选择权给用户
真正写代码就是面向过程的 把你的整个优惠流程梳理出来 然后按照这个逻辑写出来 而不是考虑面向对象的方法
使用插件模式，每次需要办一个活动，就当做一个插件。然后可以方便的加载和卸载，这样活动不会影响核心的代码。
同求大神解读
每办一次活动， 加入购物车中的商品， 计算出最后的价格， 肯定是不一样的。 所以关键是要先算出活动之后的商品的价格，然后插入数据表中。 可以考虑代理模式，和装饰者模式同时使用。
代理模式： 主要用在购物车业务逻辑层， 在数据插入购物车之前算出商品价格。
装饰者模式： 应该是促销常用的一种计算价格的解决方案。 可以实现动态为对象添加功能， 比如：VIP 9折， 全场所有商品9折两个活动一起用，用这个模式最好了。。。