设计模式学习笔记：看着挺像的Strategy Bridge Command
个人觉得策略、桥接、命令这三种模式有一定的相似度。所以放在一些，写点东西，理理思路。
策略模式的定义（个人理解：单边变化）
理解：
这种模式很常见，通常大家也都会把一部分可能有变化或者就是需要有多少变化的操作（步骤）通过接口给分离出去，自身只要有一个实现该接口的成员即可。这种就是松耦合，有人给这种写法起了个名字叫做策略模式。
打比方：
现在网络电台大同小异，诸如：豆瓣、人人。我要做一个东西把这些电台都整合起来。
那我就要先定义一个播放器类。
又因为三个电台获取歌单的方法不同，那就再定义一个接口:电台模块。里面有一个方法：获取歌单。分别实现三次。
当我需要更换电台播放歌曲的时候只需让控制类去设置播放器的电台模块,即可。 而我再添加一个新浪电台，不会影响代码。
桥接模式定义（个人理解：双边变化）
理解：
看UML图，你会发现其实桥接模式和策略模式很类似。
稍有不同的是：策略模式的context角色是一普通类，而桥接模式的abstractionImpl角色是一个抽象类的实现。
普通的类和抽象类的子类有什么区别么？ 后者可以有多种实现。
如果说：策略模式是一对多；那么桥接模式就是多对多，其核心意义就是：the two can vary independently。
打比方：
接着上面那个整合网络电台的例子继续说，
原本的播放器会依据用户行为自动调整歌曲的播放（打红心，丢垃圾桶影响选歌）。
现在我想增加一个播放器，可以顺序播放用来点播专辑（打红心，丢垃圾桶不影响选歌）。
不想把逻辑写的太乱变得难以维护，就需要把原本的播放器类的核心操作分离成一个抽象类 ，然后分别实现两个子类：调教播放器，顺序播放器。
这样就把原先的策略模式变成了桥接模式。
经过这番修改，以后如果再要加一个百度电台（concreteImplementor） 或者 可回退的播放器(abstractionImpl)。就基本不用改动其他的代码
命令模式定义 （个人理解：夹带私货）
理解：
cconcreteCommand包含receiver（负责实际工作的角色）形成一道command。
invoker包含command最终执行receiver。
如果只是invoker想要receiver做事情，顶多一个策略模式就行了，为什么要加一个command角色么？
个人理解中间加了command这个角色，主要是为了：
1、在不影响invoker、receiver代码的情况下上夹带私货。
2、invoker、receiver完全解耦
打比方 ：
如定义里说的
log：当执行command.execute的时候，还可以记下log或者其他辅助操作。这样代码不会污染invoker和receiver。
undo：当执行command.execute的时候，把数据放入command的成员里。 执行command.undo的时候就可以从成员里取出相应的数据。
macro：command里有一个command集合。可以实现宏命令。
看看能不能发到首页，关注这方面的可以讨论讨论...
