1. Command Pattern
基本定义： 把Command(Request)封装成对象，把发出命令(Invoker)的责任和执行命令(Receiver)的责任分割开，委派给不同的对象。
责任划分有什么好处？
责任约单一，内聚性越高，可重用的可能性越大，试想下，如果服务员不仅要点菜，还要去做菜，会是什么情景。
为什么把Invoker和Receiver解耦好处多？
类之间的耦合越低，可扩展的可能性越高。解耦后，更换一个服务员并不会影响厨师的工作
那么把Request封装成对象具体是什么意思呢？
在遥控器Remote Control例子中，比如我有一个‘开灯’的Request，那么就应该对应有一个LightOnCommand对象，关灯就应该有LightOffCommand
在Web应用中，我有一个add user的Request，那么就应有一个AddUserCommand去处理请求, 或者用struts的name convention就是AddUserAction.
那么在Struts中又是怎么运用Command Pattern的呢？
Client : FilterDispatcher Servlet
Invoker: ActionInvocation
Command: Action (not a must in Struts2)
ConcreteCommand：AddUserAction
Receiver: AddUserServiceImpl (not a must, depends on how many logic you want to put into concreteCommand)
Struts，你什么时候调用的setCommand()?
用户定义了Action Mapping在struts.xml里，在web container启动时，ConfigurationManager 就装载了struts.xml，当Request过来时，Struts Framework会根据当前的URL去找ConfigurationManager所对应的concreteCommand/Action, 然后这个Action会被set到ActionInvocation
Command Interface是必须的吗？
在struts1中，有一个Interface，所有的Action都必须是它的实现。但是在Struts2中，Action可以是任意的POJO，因为在Runtime的时候，具体的Action是什么，该调用它的什么方法，都可以通过配置文件（MetaData）+ Java Reflection来实现。这种新方式的好处是POJO Action没有了对框架的依赖，测试将会更加容易。缺点是因为没有interface的约束，调用Action的什么方法完全取决于默认值（比如execute）或是配置文件中的配置。若设置不妥，只有在Runtime的时候才能发现错误。
Receiver 是必须得吗？
不是，取决于你Action的厚度，如果你想让Action很轻的话，那么通常你会在Action中使用UserService.addUser()去做事情，此时的UserService就是Receiver。把Action设计的厚点，直接把addUser的logic放在Action中也是可以的。
Struts2中运用了command的思想，但并没有严格的按照其经典模型实现，而是做了些变通，这些变通乍看起来可能是有点违背设计原则，比如说取消了Action Interface，这不是反模式吗，反面向接口的编程吗，但仔细想想，这里我们真的需要这个接口吗？通过配置文件+Reflection，我们同样可以做到在Runtime的时候给ActionInvocation注入不同的Action的目的。而接口却增加了用户实现对框架的依赖，降低了程序的可测性，所以这样的变通其实是有积极意义的，虽然我们损失了一点点接口作为契约所带来的好处。
2. Interceptor Pattern
于其说这是模式，不如说这是AOP和Pipeline思想的结合，只不过Struts2中的实现非常的精巧，我不得不说这应该作为一个模式来推广。
AOP： 所谓的AOP就是preProcess and postProcess, 系统应用中，许多地方是需要面向切面的，比如log，authentication，etc...。Java Dynamic Proxy通常也是实现AOP的方式，但它是通过Java Reflection的机制，动态的产生一个被修改过的method，从而达到预处理和后处理的目的，个人觉得这种方式粗暴不够优雅，并且可扩展性不好。 不过其优点是它是内嵌在JDK中的AOP，使用比较方面，对于那些不需要扩展性的需求，动态代理也是可以考虑的。
Pipeline：分层就是把复杂的问题分层多个层次，每一层只处理问题的一小部分。通信的7层模型就是典型的范例
Interceptor Pattern： 不仅为系统进行分层，而且还提供了AOP的处理，此外，还以一种plug-in的方式为用户提供了无限扩展的可能。
应该怎么实现？
Interceptor的调用过程类似于一个栈式调用，所以想到递归是很自然的，这既避免了像Dynamic Proxy那样的class hack，又提供了更好的扩展性。
还是以Struts中的类作为例子，其类图如下：
调用过程：
Pseudo 代码：
ActionInvocation
public Result invoke(){
if( interceptors.hasNext() ){
Interceptor interceptor = interceptors.next();
result = interceptor.intercept(this);
}
else {
action.execute();//如果没有更多的Interceptor，停止递归，调用action
}
}
InterceptorImpl
public SomeInterceptor implements Interceptor{
public Result intercept(ActionInvocation actionInvocation){
//pre-processing
// 递归调用
result = actionInvocation.invoke();
//post-processing
return result;
}
}More: http://www.cnblogs.com/west-link/archive/2011/06/22/2086591.html
http://bosy.dailydev.org/2007/04/interceptor-design-pattern.html
Struts2 架构图
Struts 2 framework: http://viralpatel.net/blogs/introduction-to-struts-2-framework/
版权声明：本文为博主原创文章，未经博主允许不得转载。
