11.装饰模式（Decorator Pattern）
定义：Attach additional responsibilities to an object dynamically keeping thesame interface.Decorators provide a flexible alternative to subclassing forextending functionality.（动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。）
● Component 抽象构件Component 是一个接口或者是抽象类，就是定义我们最核心的对象，也就是最原
始的对象，如上面的成绩单。
注意：在装饰模式中，必然有一个最基本、最核心、最原始的接口或抽象类充当
Component 抽象构件。
● ConcreteComponent 具体构件
ConcreteComponent 是最核心、最原始、最基本的接口或抽象类的实现，你要装饰的就是它。
● Decorator 装饰角色
一般是一个抽象类，做什么用呢？实现接口或者抽象方法，它里面可不一定有抽象的方法呀，在它的属性里必然有一个 private 变量指向 Component 抽象构件。
● 具体装饰角色
ConcreteDecoratorA 和 ConcreteDecoratorB 是两个具体的装饰类，你要把你最核心的、最原始的、最基本的东西装饰成其他东西，上面的例子就是把一个比较平庸的成绩单装饰成家长认可的成绩单。
使用场景：
● 需要扩展一个类的功能，或给一个类增加附加功能。
● 需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
● 需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式。
12.策略模式（Strategy Pattern）
定义：Define a family of algorithms,encapsulate each one,and make theminterchangeable.（定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。）
● Context 封装角色
它也叫做上下文角色，起承上启下封装作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化。
● Strategy 抽象策略角色
策略、算法家族的抽象，通常为接口，定义每个策略或算法必须具有的方法和属性。各位看官可能要问了，类图中的 AlgorithmInterface 是什么意思，嘿嘿，algorithm 是“运算法则”的意思，结合起来意思就明白了吧。
● ConcreteStrategy 具体策略角色（多个）
实现抽象策略中的操作，该类含有具体的算法。
使用场景：
● 多个类只有在算法或行为上稍有不同的场景。
● 算法需要自由切换的场景。
● 需要屏蔽算法规则的场景。
注意事项：具体策略数量超过 4 个，则需要考虑使用混合模式
策略模式扩展：策略枚举
public enum Calculator {
//加法运算
ADD("+"){
public int exec(int a,int b){
return a+b;
}
},
//减法运算
SUB("-"){
public int exec(int a,int b){
return a - b;
}
};
String value = "";
//定义成员值类型
private Calculator(String _value){
this.value = _value;
}
/ /获得枚举成员的值
public String getValue(){
return this.value;
}
//声明一个抽象函数
public abstract int exec(int a,int b);
}
定义：
● 它是一个枚举。
● 它是一个浓缩了的策略模式的枚举。
注意：
受枚举类型的限制，每个枚举项都是 public、final、static 的，扩展性受到了一定的约束，因此在系统开发中，策略枚举一般担当不经常发生变化的角色。
致命缺陷：
所有的策略都需要暴露出去，由客户端决定使用哪一个策略。
13.适配器模式（Adapter Pattern）
定义：Convert the interface of a class into another interface clientsexpect.Adapter lets classes work together that couldn't otherwise because ofincompatible interfaces.（将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。）
类适配器：
● Target 目标角色
该角色定义把其他类转换为何种接口，也就是我们的期望接口，例子中的IUserInfo 接口就是目标角色。
● Adaptee 源角色
你想把谁转换成目标角色，这个“谁”就是源角色，它是已经存在的、运行良好的类或对象，经过适配器角色的包装，它会成为一个崭新、靓丽的角色。
● Adapter 适配器角色
适配器模式的核心角色，其他两个角色都是已经存在的角色，而适配器角色是需要新建立的，它的职责非常简单：把源角色转换为目标角色，怎么转换？通过继承或是类关联的方式。
使用场景：
你有动机修改一个已经投产中的接口时，适配器模式可能是最适合你的模式。比如系统扩展了，需要使用一个已有或新建立的类，但这个类又不符合系统的接口，怎么办？使用适配器模式，这也是我们例子中提到的。
注意事项：
详细设计阶段不要考虑使用适配器模式，使用主要场景为扩展应用中。
对象适配器：
对象适配器和类适配器的区别：
类适配器是类间继承，对象适配器是对象的合成关系，也可以说是类的关联关系，这是两者的根本区别。（实际项目中对象适配器使用到的场景相对比较多）。
14.迭代器模式（Iterator Pattern）
定义：Provide a way to access the elements of an aggregate object sequentiallywithout exposing its underlying representation.（它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。）
● Iterator 抽象迭代器
抽象迭代器负责定义访问和遍历元素的接口，而且基本上是有固定的 3 个方法：first()获得第一个元素，next()访问下一个元素，isDone()是否已经访问到底部（Java 叫做 hasNext()方法）。
● ConcreteIterator 具体迭代器
具体迭代器角色要实现迭代器接口，完成容器元素的遍历。
● Aggregate 抽象容器容器
角色负责提供创建具体迭代器角色的接口，必然提供一个类似 createIterator()这样的方法，在 Java 中一般是 iterator()方法。
● Concrete Aggregate 具体容器
具体容器实现容器接口定义的方法，创建出容纳迭代器的对象。
ps：迭代器模式已经被淘汰，java 中已经把迭代器运用到各个聚集类
（collection）中了，使用 java 自带的迭代器就已经满足我们的需求了。
15.组合模式（(Composite Pattern)）
定义：Compose objects into tree structures to represent part-wholehierarchies.Composite lets clients treat individual objects and compositions ofobjects uniformly.（将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。）
● Component 抽象构件角色
定义参加组合对象的共有方法和属性，可以定义一些默认的行为或属性，比如我们例子中的 getInfo 就封装到了抽象类中。
● Leaf 叶子构件
叶子对象，其下再也没有其他的分支，也就是遍历的最小单位。
● Composite 树枝构件
树枝对象，它的作用是组合树枝节点和叶子节点形成一个树形结构。
树枝构件的通用代码：
public class Composite extends Component {
//构件容器
private ArrayList<Component> componentArrayList = new
ArrayList<Component>();
//增加一个叶子构件或树枝构件
public void add(Component component){
this.componentArrayList.add(component);
}
//删除一个叶子构件或树枝构件
public void remove(Component component){
this.componentArrayList.remove(component);
}
//获得分支下的所有叶子构件和树枝构件
public ArrayList<Component> getChildren(){
return this.componentArrayList;
}
}
使用场景：
● 维护和展示部分-整体关系的场景，如树形菜单、文件和文件夹管理。
● 从一个整体中能够独立出部分模块或功能的场景。
注意：
只要是树形结构，就考虑使用组合模式。
16.观察者模式（Observer Pattern）
定义：Define a one-to-many dependency between objects so that when oneobject changes state,all its dependents are notified and updated automatically.（定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。）
● Subject 被观察者
定义被观察者必须实现的职责，它必须能够动态地增加、取消观察者。它一般是抽象类或者是实现类，仅仅完成作为被观察者必须实现的职责：管理观察者并通知观察者。
● Observer 观察者
观察者接收到消息后，即进行 update（更新方法）操作，对接收到的信息进行处理。
● ConcreteSubject 具体的被观察者
定义被观察者自己的业务逻辑，同时定义对哪些事件进行通知。
● ConcreteObserver 具体的观察者
每个观察在接收到消息后的处理反应是不同，各个观察者有自己的处理逻辑。
被观察者通用代码：
public abstract class Subject {
//定义一个观察者数组
private Vector<Observer> obsVector = new Vector<Observer>();
//增加一个观察者
public void addObserver(Observer o){
this.obsVector.add(o);
}
//删除一个观察者
public void delObserver(Observer o){
this.obsVector.remove(o);
}
//通知所有观察者
public void notifyObservers(){
for(Observer o:this.obsVector){
o.update();
}
}
}
使用场景：
● 关联行为场景。需要注意的是，关联行为是可拆分的，而不是“组合”关系。
● 事件多级触发场景。
● 跨系统的消息交换场景，如消息队列的处理机制。
注意：
● 广播链的问题
在一个观察者模式中最多出现一个对象既是观察者也是被观察者，也就是说消息最多转发一次（传递两次）。
● 异步处理问题
观察者比较多，而且处理时间比较长，采用异步处理来考虑线程安全和队列的问题。
17.门面模式（Facade Pattern）
定义：Provide a unified interface to a set of interfaces in a subsystem.Facadedefines a higher-level interface that makes the subsystem easier to use.（要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。）
● Facade 门面角色
客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类。
● subsystem 子系统角色
可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。
使用场景：
● 为一个复杂的模块或子系统提供一个供外界访问的接口
● 子系统相对独立——外界对子系统的访问只要黑箱操作即可
● 预防低水平人员带来的风险扩散
注意：
●一个子系统可以有多个门面
●门面不参与子系统内的业务逻辑
18.备忘录模式（Memento Pattern）
定义：Without violating encapsulation,capture and externalize an object's internalstate so that the object can be restored to this state later.（在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。）
● Originator 发起人角色
记录当前时刻的内部状态，负责定义哪些属于备份范围的状态，负责创建和恢复备忘录数据。
● Memento 备忘录角色（简单的 javabean）
负责存储 Originator 发起人对象的内部状态，在需要的时候提供发起人需要的内部状态。
● Caretaker 备忘录管理员角色（简单的 javabean）
对备忘录进行管理、保存和提供备忘录。
使用场景：
● 需要保存和恢复数据的相关状态场景。
● 提供一个可回滚（rollback）的操作。
● 需要监控的副本场景中。
● 数据库连接的事务管理就是用的备忘录模式。
注意：
●备忘录的生命期
●备忘录的性能
不要在频繁建立备份的场景中使用备忘录模式（比如一个 for 循环中）。
clone 方式备忘录：
● 发起人角色融合了发起人角色和备忘录角色，具有双重功效
多状态的备忘录模式
● 增加了一个 BeanUtils 类，其中 backupProp 是把发起人的所有属性值转换到HashMap 中，方便备忘录角色存储。restoreProp 方法则是把 HashMap 中的值返回到发起人角色中。
BeanUtil 工具类代码：
public class BeanUtils {
//把 bean 的所有属性及数值放入到 Hashmap 中
public static HashMap<String,Object> backupProp(Object bean){
HashMap<String,Object> result = new
HashMap<String,Object>();
try {
//获得 Bean 描述
BeanInfo
beanInfo=Introspector.getBeanInfo(bean.getClass());
//获得属性描述
PropertyDescriptor[]
descriptors=beanInfo.getPropertyDescriptors();
//遍历所有属性
for(PropertyDescriptor des:descriptors){
//属性名称
String fieldName = des.getName();
//读取属性的方法
Method getter = des.getReadMethod();
//读取属性值
Object fieldValue=getter.invoke(bean,new
Object[]{});
if(!fieldName.equalsIgnoreCase("class")){
result.put(fieldName, fieldValue);
}
}
} catch (Exception e) {
//异常处理
}
return result;
}
//把 HashMap 的值返回到 bean 中
public static void restoreProp(Object bean,HashMap<String,Object>
propMap){
try {
//获得 Bean 描述
BeanInfo beanInfo =
Introspector.getBeanInfo(bean.getClass());
//获得属性描述
PropertyDescriptor[] descriptors =
beanInfo.getPropertyDescriptors();
//遍历所有属性
for(PropertyDescriptor des:descriptors){
//属性名称
String fieldName = des.getName();
//如果有这个属性
if(propMap.containsKey(fieldName)){
//写属性的方法
Method setter = des.getWriteMethod();
setter.invoke(bean, new
Object[]{propMap.get(fieldName)});
}
}
} catch (Exception e) {
//异常处理
System.out.println("shit");
e.printStackTrace();
}
}
}
封装得更好一点：保证只能对发起人可读
●建立一个空接口 IMemento——什么方法属性都没有的接口，然后在发起人
Originator 类中建立一个内置类（也叫做类中类）Memento 实现 IMemento 接口，同时也实现自己的业务逻辑。
19.访问者模式（Visitor Pattern）
定义：Represent an operation to be performed on the elements of an objectstructure. Visitor lets you define a new operation without changing the classes ofthe elements on which it operates. （封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。）
● Visitor——抽象访问者
抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是 visit 方法的参数定义哪些对象是可以被访问的。
● ConcreteVisitor——具体访问者
它影响访问者访问到一个类后该怎么干，要做什么事情。
● Element——抽象元素
接口或者抽象类，声明接受哪一类访问者访问，程序上是通过 accept 方法中的参数来定义的。
● ConcreteElement——具体元素
实现 accept 方法，通常是 visitor.visit(this)，基本上都形成了一种模式了。
● ObjectStruture——结构对象
元素产生者，一般容纳在多个不同类、不同接口的容器，如 List、Set、Map 等，在项目中，一般很少抽象出这个角色。使用场景：
● 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作，也就说是用迭代器模式已经不能胜任的情景。
● 需要对一个对象结构中的对象进行很多不同并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。
20.状态模式（复杂）
定义：Allow an object to alter its behavior when its internal state changes.Theobject will appear to change its class.（当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。）
● State——抽象状态角色
接口或抽象类，负责对象状态定义，并且封装环境角色以实现状态切换。
● ConcreteState——具体状态角色
每一个具体状态必须完成两个职责：本状态的行为管理以及趋向状态处理，通俗地说，就是本状态下要做的事情，以及本状态如何过渡到其他状态。
● Context——环境角色
定义客户端需要的接口，并且负责具体状态的切换。
使用场景：
● 行为随状态改变而改变的场景
这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。
● 条件、分支判断语句的替代者
注意：
状态模式适用于当某个对象在它的状态发生改变时，它的行为也随着发生比较大的变化，也就是说在行为受状态约束的情况下可以使用状态模式，而且使用时对象的状态最好不要超过 5 个。
21.解释器模式（Interpreter Pattern）
（少用）
定义：Given a language, define a representation for its grammar along with aninterpreter that uses the representation to interpret sentences in the language.（给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。）
● AbstractExpression——抽象解释器
具体的解释任务由各个实现类完成，具体的解释器分别由 TerminalExpression 和Non-terminalExpression 完成。
● TerminalExpression——终结符表达式
实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。具体到我们例子就是 VarExpression类，表达式中的每个终结符都在栈中产生了一个 VarExpression 对象。
● NonterminalExpression——非终结符表达式
文法中的每条规则对应于一个非终结表达式，具体到我们的例子就是加减法规则分别对应到 AddExpression 和 SubExpression 两个类。非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式。
● Context——环境角色
具体到我们的例子中是采用 HashMap 代替。
使用场景：
● 重复发生的问题可以使用解释器模式
● 一个简单语法需要解释的场景
注意：
尽量不要在重要的模块中使用解释器模式，否则维护会是一个很大的问题。在项目中可以使用 shell、JRuby、Groovy 等脚本语言来代替解释器模式，弥补 Java 编译型语言的不足。
22.享元模式（Flyweight Pattern）
定义：Use sharing to support large numbers of fine-grained objects efficiently.（使用共享对象可有效地支持大量的细粒度的对象。）对象的信息分为两个部分：内部状态（intrinsic）与外部状态（extrinsic）。
● 内部状态
内部状态是对象可共享出来的信息，存储在享元对象内部并且不会随环境改变而改变。
● 外部状态
外部状态是对象得以依赖的一个标记，是随环境改变而改变的、不可以共享的状态。
● Flyweight——抽象享元角色
它简单地说就是一个产品的抽象类，同时定义出对象的外部状态和内部状态的接口或实现。
● ConcreteFlyweight——具体享元角色
具体的一个产品类，实现抽象角色定义的业务。该角色中需要注意的是内部状态处理应该与环境无关，不应该出现一个操作改变了内部状态，同时修改了外部状态，这是绝对不允许的。● unsharedConcreteFlyweight——不可共享的享元角色不存在外部状态或者安全要求（如线程安全）不能够使用共享技术的对象，该对象一般不会出现在享元工厂中。
● FlyweightFactory——享元工厂
职责非常简单，就是构造一个池容器，同时提供从池中获得对象的方法。
享元工厂的代码：
public class FlyweightFactory {
//定义一个池容器
private static HashMap<String,Flyweight> pool= new
HashMap<String,Flyweight>();
//享元工厂
public static Flyweight getFlyweight(String Extrinsic){
//需要返回的对象
Flyweight flyweight = null;
//在池中没有该对象
if(pool.containsKey(Extrinsic)){
flyweight = pool.get(Extrinsic);
}else{
//根据外部状态创建享元对象
flyweight = new ConcreteFlyweight1(Extrinsic);
//放置到池中
pool.put(Extrinsic, flyweight);
}
return flyweight;
}
}
使用场景：
● 系统中存在大量的相似对象。
● 细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份。
● 需要缓冲池的场景。
注意：
● 享元模式是线程不安全的，只有依靠经验，在需要的地方考虑一下线程安全，在大部分场景下不用考虑。对象池中的享元对象尽量多，多到足够满足为止。
● 性能安全：外部状态最好以 java 的基本类型作为标志，如 String，int，可以提高效率。
23.桥梁模式（Bridge Pattern）
定义：Decouple an abstraction from its implementation so that the two can varyindependently.（将抽象和实现解耦，使得两者可以独立地变化。）● Abstraction——抽象化角色它的主要职责是定义出该角色的行为，同时保存一个对实现化角色的引用，该角色
一般是抽象类。
● Implementor——实现化角色
它是接口或者抽象类，定义角色必需的行为和属性。
● RefinedAbstraction——修正抽象化角色
它引用实现化角色对抽象化角色进行修正。
● ConcreteImplementor——具体实现化角色
它实现接口或抽象类定义的方法和属性。
使用场景：
● 不希望或不适用使用继承的场景
● 接口或抽象类不稳定的场景
● 重用性要求较高的场景
注意：
发现类的继承有 N 层时，可以考虑使用桥梁模式。桥梁模式主要考虑如何拆分抽象和实现。
网友评论