设计模式（十二）创建类模式比较

在看完基础的设计模式之后，回头想想，其实大部分模式仍然是半瓶水。对于一种简单的模式稍加变化，模式里面的各个部分应该如何继续抽象？
1.策略模式中，环境角色似乎是不需要的。但在实际的运用中，它在处理多角色情况下，是必不可少的。这些都需要加深理解。
2.状态模式和命令模式，在形式上比较类似，封装上都具有可循的踪迹。那么具体每一个部分，究竟在何时可以发挥出它的作用？这是需要深入理解的。
3.当我们扩展的时候，可以基于原来的哪些部分来抽象，创造出合适系统需要的结果，进一步提升封装和扩展的优化？目前自己离这一步还很远。
所以，以为自己花了几个月看完设计模式已经很久了，其实离真正的精髓还很远。
这么学习速度太慢了。是该继续深入，还是切换到下一本书呢？
和同学比较一下，我看到有的人读一本书超过了22个小时。我几本书加起来也就差不多这个数量级吧。或者是我自己太贪快了。并且，有很多的扩展内容还没有仔细看。

代理模式&装饰模式

其实这两张图我没看出来有啥相似点。不过书中另外一个例子就有点像了：

装饰模式中省略抽象装饰角色后，两者代码基本上相同:

代理模式是把当前的行为或功能委托给其他对象执行，代理类负责接口限定：是否可以调用真实角色，以及是否对发送到真实角色的消息进行变形处理，它不对被主题角色（也就是被代理类）的功能做任何处理，保证原汁原味的调用。
装饰模式是在要保证接口不变的情况下加强类的功能，它保证的是被修饰的对象功能比原始对象丰富（当然，也可以减弱），但不做准入条件判断和准入参数过滤，如是否可以执行类的功能，过滤输入参数是否合规等，这不是装饰模式关心的。

装饰模式是一个比较拘谨的模式，在实际应用中接触比较少。我们考虑在类似场景中，如何更好的抽象角色，减少代码的修改比较好。

策略模式&命令模式

我主要想比较两者的环境角色和调用者。先看看策略模式：

这里的Context只是一个简单的封装，感觉没啥用。

再看看命令模式：

这里的Involver也是一层简单的封装：


为此，我参考了文章：https://www.iteye.com/blog/zhanche2011-1169948
该文章中提出了一个说法：如果每个策略需要额外的操作，那么可以通过将Context作为参数传入，以减少不同策略的个性化需要。比如，引用计数或者是调用者需要传入更多的可变数据。
以此类推，invoker也可以这样应用。至于实际中是否是需要，我再参考其他资料。不过从目前看来，这两个家伙如果在调用者多次呼叫的情况下，确实可以减少代码的修改。我们只需要在创建命令的时候修改为不同的命令和接受者，后续再通过invoker来调用，就不用再修改代码了。
比如我们点菜的时候，只呼叫服务员，不要直接叫不同的厨师。这道菜最终是哪位厨师做，我们就不用管了。