命令模式、template method模式、工厂方法模式的比较

强烈推荐GOF的《设计模式》，不用看什么j2ee设计模式。GOF的书的确经典。看过之后，精神爽，身体棒，吃嘛嘛香！

 

命令模式的类图，网上到处都有！

一般包括：client，invoker，Command接口，具体的command实现，receiver。

首先说明一下，命令模式的场景：实体解耦和时间解耦。嘛意思呢？就是命令发出者和接收者两个不互相依赖了，时间顺序上也是可以有间断的，即命令发出者不必在那里等着接收者，两者在时间上是分开的。

举个小例子：国家（ivoker，发起人）发出扫黄打非的命令（封装了行动信息和指标）啦，各地警察叔叔们（接收者）就出来巡逻（干活）啦，专拣那个红灯区和一些洗浴中心下手。

整个过程中，国家只需要下个命令就好，同时这个命令不是自己跑着去扫黄的，而是由警察叔叔们去做具体的工作。

 

template method模式场景说明：格式化动作。

举个小例子：男的跟女的都上厕所，但是方式不一样。这个时候就是可以在人这一层概念上抽象出一个 goToBathroom() 模板方法，子类男人和女人各自实现这个具体动作。

所以，template method模式是解耦具体动作的实现。

 

工厂方法模式场景说明：工厂造对象。（这句话说得多么直白。。。我自己都被感动了）

抽象点说：在使用工厂这个家伙的时候，一般情况下，可以实现调用端跟具体对象创建过程的依赖和对具体对象的依赖。

举个例子：我们随便进入一栋楼，里面有厕所。问题来了，我们要上厕所，要用马桶。造马桶时，肯定没问过我们，我想也不会有人来问我们要那种，那么我们的需求就是要用马桶上大号。

所以这里就实现了：

使用者跟制造工厂的解耦（你不知道具体是哪个厂商，但是你肯定知道，它，也就是你心爱的马桶，肯定是某个具体的马桶厂子造出来的）

使用者跟具体马桶的解耦（你只需要一个马桶，对不？有它该有的功能就行了）

使用者仅仅依赖于工厂的接口和马桶的接口就好。

 

所以，上面三个模式都很努力的告诉我们，别把具体实现跟上层类耦合起来，尤其是避免上层依赖下层，如果出现这种情况，就考虑ioc，让上层依赖于接口。

但是，他们三者之间有什么相似之处呢：

都提供了统一方法；

都解耦了上层跟具体业务的实现；

command和factory尤其相似，就是将调用者跟行动者分离。

不同之处：

1）命令模式强调命令的发出者、实现者、命令的独立，使得发出者仅仅关心自己命令，接收者好好完成任务，命令的实现就是关联这两者；

2）工厂方法强调使用者、工厂接口、业务接口（就是工厂用来生产的那种东西，但是不确定），使用者跟工厂和生产出来的东西都解耦。

3）模板方法，强调模板，强调局部实现的解耦，以便重用通用动作，减少代码重复。

 

再想想，看看还有什么要继续补充的。。。。。