读故事后感
- 无形装逼, 黑了眼圈
小故事看完, 小例子也有了
定义: 在软件系统中, "行为请求者"与"行为实现者"通常呈现一种"紧耦合". 但在某些场合, 比如要对行为进行"记录,撤销/重做,事务"等处理, 这种无法抵御的紧耦合是不适合的. 如何将"行为请求者"与"行为实现者"解耦?将这一组行为抽象为对象. 实现二者之间的松耦合. 这就是命令者模式(Command Pattern).
- invoker与command组合关系 invoker是实际下达任务的组件
- command抽象细节接口
- receiver 具体实施
整个简单明了,nice
原文中的任务分配例子, 这次我决定自己想个例子
开始讲故事
<<星系大爆炸>>
小邓是太阳系的一名IT万能兵, 公元2017年的某一天, 修了一天的BUG, 回来还没喝上口热乎的, 电话来了, 是业务专家赵哥笑眯眯对我说:"小邓啊, 这有个新的任务, 明天去那乌巢看下他们的系统环境, 还有去之前把那个代码生成修一下".
小邓满心中自然不爽, 我还没休息呢, 也不是啥大难事, 随口: "好的", 没啥事嘛, 第二天嘛, 跟今天没什么关系
还没一会, 老王(业务专家)来了:"小邓啊, 不好意思想起来了, 听说你明天去乌巢, 从乌巢回来的时候买些苹果, 看到西瓜的话买一个". oh my god. 心中咒骂, 这还没完, 老刘来个电话, 严肃的对我说:" 这有个特别紧急的事情, 我们星系的邻居太阴系的官方网站开下来卡死, 还要客户去挖矿, 加班赶紧做了"
小邓心想完了, mmp啊, 命苦啊, 这么多事情怎么记得住
----------------------------------------------------------代码部分就不献上了---------------------------------------------
搞完事情, 小邓想起来我这不是刚刚看了左先锋的设计模式之命令者模式吗? 这不刚刚好契合我这场景, prefect
就是干啊, 先分析下
- 缺了个中间环节, 那就是没人整理任务, 按优先级分发通知
- 业务员与小邓关联的太多, 就是高耦合
- 在加个插队功能
写着写着就窜题了, 变成抢红包的功能了, 把核心代码附上
public static double getRandomMoney(double moneys,int numbers) {
// numbers 参与人数 每次都会变少
// money 剩余金额
if (numbers == 1) {
return (double) Math.round(moneys * 100) / 100;//返回最接近参数的 long
}
Random r = new Random();
double min = 0.01; //最小金额
double max = moneys / numbers * 2;//最大金额 平均数*2
double money = r.nextDouble() * max; //随机金额
money = money <= min ? 0.01: money; //判断大小
money = Math.floor(money * 100) / 100;//小于等于接近该值的整数
return money;
}
uml图用原文的
多了一层关系
- productManager与programmer的关系, 经理与程序员的关系
干货:
- 行为请求者和行为实现者解耦
- 行为请求者只需要将命令发给调用者, 不再主动的去让行为实现者产生行为, 符合单一原则
- 方便撤销/重做等事务功能
- 请求排队有序执行
- 将请求组合使用
- 缺点: 大部分设计模式一样, 增加系统的复杂性, 看原文中的类的数量就是知道了, 鱼与熊掌不可兼得
大概弄了一半了, 明天继续