Abstract作为抽象类和抽象方法，主要还是在聚合子类的通用性上起到作用，往往出现在重构过程中自然而然形成的一种层次结构～希望将多个子类的通用方法和逻辑提取到父层的抽象类。
这种重构情况的最极致表现就是：若再加入新的子类，子类只需要实现抽象类的abstract方法，而且可能就只用几句话的简单声明，或者做一些属性设置就可以了，往往只是用于区分子类的特征，真正的逻辑处理实际上是在抽象类的方法内实现。这样就极大地简化了子类的代码逻辑量，实现子类层去耦合，抽象层高内聚的极佳效果。
上图中可以看到流水线作为一个统一的对象抽象概念，下辖了分拣、抽检、加工等子工序。。。但是流水线是一个密集的工序，肯定具有大量上下文处理逻辑在里面，那么就加上一个抽象的类，交给抽象类来做，各个子工序只需要将自己份内的工序实现好就可以了。由抽象类来实现工序连接，上下文管理等，统一成为接口方法具体实现的逻辑代表。
咱们再举个例子，Java MVC框架的鼻祖Struts Framework，是由Craig R. McClanahan设计创造。我相信很多人都听说过Struts框架，其设计的Action对象都已经成为Web开发中控制的代名词。这也是最早基于JavaEE的servlet规范的WEB层框架，让老早的程序员见识到了MVC是什么样子（当然1.0并不是彻底的MVC），
好，我们看看他的一个非常简化的架构图，我们重点是说明它对Abstract的使用：
Struts1.x版本的内部使用了过滤链模式和命令模式的组合，当客户端向Servlet发起请求，那么作为Servlet的Struts实现ActionServlet就将请求调度进了Struts框架来处理。
我们可以看到图中ActionCommand作为接口抽象，ActionCommandBase作为命令链的统一入口层抽象，AbstractCreateActoin、AbstractAuthorizeAction、AbstractExectionAction作为对业务Action的创建、授权和执行（Execture）的命令抽象层，最后一层CreateAction、AuthorizeAction、ExectionAction为父类提供具体Action的实现类。另外还有选择、跳转、异常等命令，
就是以命令链条串起来的形式，从Action被创建或选择，到Action执行以及跳转的Action全生命周期管理。
那么我们从这个示例中看到了抽象（abstract）被大量的使用，主要就是通过设计模式的引入，将“业务执行（Action）”这个抽象的概念，在流程中用命令的方式进行了全生命周期的管理。那么程序员写的Action就彻底与Servlet解耦了，中间是通过Struts框架的过滤链和命令两种设计模式的操作，使得控制层彻底独立出来。备注：MVC的模型和视图不在这个架构描述当中。
因此无论是以后的Struts2.0也好，Spring MVC也好，基本上都是沿着Struts1.0的设计思想进行不断的优化。但是大体的方向在那个时候都已经成型了。唯独是面向组件的JSF标准是另一种思路了，顺便提一下，JSF的最初的规范设计还是Craig R. McClanahan操刀的。
