zxc_user的博客

其实用了很多设计模式后发现很多时候都跟抽象类、策略、模板等基本模式脱不了关系，个人认为设计模式绝对是有利于编码的，因为在思考的过程中会自然的把一些可以通用的逻辑封装起来，比如getGame(), 以及appKey和rootPath的获取如果有合适的场景，也建议大家可以考虑一下如何进行设计，在以后的开发中会带来比较大的变化，比如在下一个游戏的对接，只需要实现子类即可了。

订单金额：用户下单时支付的金额，这个最好理解产品分成：也就是跟其他人合做以后我方能分到的金额，举个例子，比如用户订单金额是 100 块，我方的分成是 80%，那么也就是我方能得到 80 块联运商分成：跟产品分成类似，就是说我方还需要分去一部分的前给联运商（比如广告商，巨量，快手等），一般是不高的，也就10%左右综合例子：订单金额 100 块，产品分成 80%，联运商分成10%，那么最终我方得到的金额就是如下的计算公司 100 * （80 -10）% = 70 块。

主要采用的就是策略模式+模板模式,意义分别体现在模板模式: 把基本的校验信息,比如活动是不是存在,角色是不是存在,角色是不是有参与某个活动逻辑都放在AbstractRebateActivityRecordHandler类中进行处理,这样的好处是其他几种中奖时前置判断条件就被统一了,假设以后要调整可以统一调整即可策略模式: 把每种中奖逻辑单独用类封装起来,自己去实现要过滤的逻辑相互不影响,也更容易找到对应的地方进行修改,后续如果有其他的中奖记录根据这种类型添加实现类即可。

设计模式-命令行模式的使用

状态模式