现在的位置: 首页 > 编程 > 正文

设计模式之命令模式之讲故事(十三)

2017年05月03日 编程 ⁄ 共 1473字 ⁄ 字号 暂无评论

这篇好玩, 讲故事, 我烦躁的内心啊


读故事后感

  • 无形装逼, 黑了眼圈

小故事看完, 小例子也有了

定义: 在软件系统中, "行为请求者"与"行为实现者"通常呈现一种"紧耦合". 但在某些场合, 比如要对行为进行"记录,撤销/重做,事务"等处理, 这种无法抵御的紧耦合是不适合的. 如何将"行为请求者"与"行为实现者"解耦?将这一组行为抽象为对象. 实现二者之间的松耦合. 这就是命令者模式(Command Pattern).

uml

  • 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的关系, 经理与程序员的关系

干货:

  1. 行为请求者和行为实现者解耦
  2. 行为请求者只需要将命令发给调用者, 不再主动的去让行为实现者产生行为, 符合单一原则
  3. 方便撤销/重做等事务功能
  4. 请求排队有序执行
  5. 将请求组合使用
  6. 缺点: 大部分设计模式一样, 增加系统的复杂性, 看原文中的类的数量就是知道了, 鱼与熊掌不可兼得

大概弄了一半了, 明天继续

 

给我留言

您必须 [ 登录 ] 才能发表留言!

×