Behavior Patterns
| Chain of Responsibilty Servlet的Http请求动态响应 The Command Pattern Servlet、Struts、JUnit The Interpreter Pattern 根据字符指令输出：指定动作、定制语言：DDL、DML、转换XML文档的XSL The Iterator Pattern 拉模型 遍历Java的链表、散列等数据集合 The Mediator Pattern 通信、调用 The Observer Pattern MVC、Structs The State Pattern 状态管理 StateManager The Stragey Pattern 算法管理 Context 实例化算法类选择 The Template Pattern Refactor、OSCache、Junit The Visitor Pattern 拉模型 Spirng的IOC |
Chain of Responsibilty 责任链模式
| 场景 |
| 多个类处理一个相同的request，却无需相互知晓。 系统的request响应处理机制：request 沿着响应链传递，直至遇到能处理的类 实现：所有request的处理类穿起来。[主要：添加处理类和激发处理类] |
| 应用 |
| JFC的MFC的消息处理 Servlet：动态响应Http请求，将request传给多个Servlet Servlet的Filter：是Decorator模式与Chain of Responsibilty模式的结合体 |
The Command Pattern 命令模式
| 场景 |
| 场景：根据不同request执行相应处理代码。 核心：处理代码分别封装到不用的具有统一激活接口类中。 借助数组或散列等对处理类进行管理和优化其激发过程，使request的传递与处理代码分离 Chain 相同request 将传递流程以链式或树型结构管理起来，为处理代码的激发顺序，提供很好的灵活性。 Command 不同request 简化和优化request到处理代码的传递，为request的扩展提供了良好的支持。 |
| 应用 |
| Servlet： 完全遵照Command模式。 每个Servlet都包含两个激发函数doGet和doPost。激活Servlet的URL或Map则在部署文件里设定。 JUnit： 以为Command基础 TestCase需要通过TestSuit以树型的结构组织起来。这样必须将所有TestCase设计成具有统一激活接口的类。 |
The Interpreter Pattern 解释器模式
| 场景 |
| 系统适用专门的语言来表述其所能进行的操作 定制语言：SQL 定制语言引入时机： 1.程序必须解释执行任意的字符指令，程序以字符指令为输入，根据指令执行不同动作。如‘：数学运算、数理统计、DDL 2.程序必须产生多种多样的输出结果，尽管这些输出结果和执行流程各异，但它们执行的操作步骤却是相同的。如报表软件、 数据库的DML、转换XML文档的XSL等。 定制语言与XML：XML是一种元语言，可以基于其上构建不同的应用语言。Struts |
| springmvc：解释器 ？？？？ |
The Iterator Pattern
| 场景 |
| 允许通过标准的接口，遍历某个集合中的数据而无需关心其内部的数据组织结构。 此外，还可以定制特殊的Iterator来过滤返回的数据。 应用：Iterator，如Java的链表、散列等数据集合的遍历，数据库查询返回的数据集遍历 接口定义： Iterator ： 组织树型结构数据 算法：深度优先、广度优先 Composite：每个节点所包含子节点的遍历 算法：屏蔽具体的遍历算法 |
| 实现 |
 |
The Mediator pattern 中介者模式
| 场景 |
| Mediator 唯一包含类函数调用细节的类，其余所有类都是通过它来实现相互通信，从而隔离各个类，延续系统的松耦合结构 Mediator、Factory和Facade： 系统通常采用分而治之的策略划分成多个模块。模块的结构设计主要面临三方面的问题。 <1>.模块间的通信 <2>.模块内各类的相互调用 <3>.创建和初始化管理 Mediator、Factory和Facade：设计出结构优化规范的模块。 |
| 实现 |
  |
The Obeserver pattern 观察者模式
| 场景 |
| 需求：同时将数据以不同的形式显示出来，且显示要能及时反映数据的变更。 传统做法： 数据逻辑与表示逻辑混合在一起 Obeserver ：数据和表现形式彻底隔离，为表现形式的多样化提供最大的弹性。 |
| 原理 |
| Obeserver 模式：将数据逻辑（Subject）及其表现逻辑（Observers）完全分离，分别封装到不同的类中。 |
| 实现 |
  |
| MVC：（Model—Viem—Controller） 核心思想：数据模型（业务逻辑）与表现逻辑相互隔离。[MVC与Obeserver模式类似] Contorller负责与客户交互，根据请求调用M和V的功能。 单体项目：Controller，与M或C结合 分布式项目：Controller独立，负责：访问协议、请求分发、安全认证、日志记录和异常处理。 Struct： |
The State pattern
| 场景 |
| 需求：多状态下，行为相异。 if-else 或switch：逻辑含糊 Sate： 使得系统方式简洁。 核心思想：状态不同的各个部分用函数概括出来，集中提取成接口，或虚类 |
| 实现 |
  |
| 原理 |
| 状态的差异通常只是引起程序某些方面的行为不同，故可以将存在差别的地方分别用函数概括总结出来，再把这些函数集中形成接口，或者虚类。然后针对不同的状态来分别编写其实现，并创建StateManager来管理。 这样：只需要通过StateManager来工作，将不同状态的处理代码与之隔离开，因此变得简洁易懂。系统的弹性和可维护性都得到提升。 |
The Strategy pattern
| 场景 |
| 系统的某些操作存在多种算法。 核心思想：使用不同算法的各个部分用函数概括出来，集中提取成基类。 然后就可以针对不同的算法写实现，同样还需Context类把这些类管理起来；。 |
| 实现 |
| Strategy 与 State 1.实例化 Strategy的Context： 实例化指定的算法类 State的StateManager：初始化时创建所有状态的处理类 2.封装与功能 Strategy 封装算法，做相同的事情 State 封装状态，做不同的操作 3.频率 Strategy 无 State 频繁状态切换跳转 |
The Template pattern
| 场景 |
| 创建一个基类，将某些方法留给子类实现。 即：定义基类[往往是虚类]，再在子类中覆盖实现其父类某些函数。 用途：Refactor、代码重用、体系结构优化 |
| 核心思想 |
| 1>策略与方法分离 将程序的主题逻辑和策略在基类中实现，而将某些方面的具体实现细节留给子类。 2>提取公共部分 |
| 对比 |
| Template： 静态 分离策略与方法 [ 不适合运行期动态变化的应用环境 ] 单继承 State： 动态 分离策略与方法 Strategy： 动态 分离策略与方法 |
| 实现 |
  |
The Visitor pattern访问者模式
| 场景 |
| 解决数据访问的问题。遍历对象，并对其中每一个都执行一些的处理操作。 场景一：欲访问的对象由不用类实现，编程接口不同。 场景二：遍历对象时，遍历代码复杂而重复 步骤： 1，创建Vistor类，在其中实现visit（*）函数 2，所有被访问的对象都要实现函数 public void accept（Visitor v）{ v.visit(this); // call visitor method } |
| 应用 |
| （JDBC：除了数据处理，其他部分基本相同。） spring：把数据处理逻辑封装到用户定义的Visitor中，而框架则负责初始化并执行SQL语句、遍历数据集合和释放资源。 如此一来JDBC的编程的冗余代码得到彻底消除且实现了反控。 |
| 对比 [数据读取模式不同] |
| Visitor 推模型 充分利用OOP的多态简化代码 Iterator 拉模型 简单直观 |
