(六) state模式
State模式在实际使用中比较多,适合"状态的切换".因为我们经常会使用
If elseif else 进行状态切换, 如果针对状态的这样判断切换反复出现,
我们就要联想到是否可以采取State模式了.
这里的状态切换是"开关状态切换" 和" 一般的状态判断"是有一些区别的,
"一般的状态判断"也是有 if..elseif结构,例如:
if (which==1) state="hello";
else if (which==2) state="hi";
else if (which==3) state="bye";
这是一个 "一般的状态判断",state值的不同是根据which变量来决定的,
which和state没有关系.如果改成:
if (state.euqals("bye")) state="hello";
else if (state.euqals("hello")) state="hi";
else if (state.euqals("hi")) state="bye";
这就是 "开关切换状态",是将state的状态从"hello"切换到"hi",
再切换到""bye";在切换到"hello",好象
一个旋转开关,这种状态改变就可以使用State模式了.
如果单纯有上面一种将"hello"-->"hi"-->"bye"-->"hello"这一个方向切换,
也不一定需要使用State模式,因为State模式会建立很多子类,复杂化,但是如果又发生另外
一个行为:将上面的切换方向反过来切换,或者需要任意切换,就需要State了.
如果将上面的切换方向反过来，其实也不一定要使用state.如果切换时行为非常简单，我们
可以仍然直接用if else或者switch结构，只有在状态切换时涉及到复杂的具体行为时才真正
需要状态切换。
例如: 银行帐户, 经常会在Open 状态和Close状态间转换。
例如: 经典的TcpConnection, Tcp的状态有创建 侦听 关闭三个,并且反复转换,其创建、侦听、
关闭的具体行为不是简单一两句就能完成的,适合使用State。
例如:信箱POP帐号, 会有四种状态, start HaveUsername Authorized quit,每个状态对应的
行为应该是比较大的.适合使用State
例如:在工具箱挑选不同工具,可以看成在不同工具中切换,适合使用State.如 具体绘图程序,
用户可以选择不同工具绘制方框 直线 曲线,这种状态切换可以使用State.
(七) strategy模式
Strategy是属于设计模式中 对象行为型模式,主要是定义一系列的算法,把这些算法一个个
封装成单独的类.Strategy其实是对不同行为的一种封装。如下：
ConcreteStrategyC csc = new ConcreteStrategyC();
Context c = new Context(csc);
c.contextInterface();
c.setStrategy(new ConcreteStrategyB());
c.contextInterface();
ConcreateStrategyC和ConcreteStrategyB都是继承自strategy接口，是不同的行为，
在c.contextInterface方法中其实就是调用不同的行为。
_strategy.algorithmInterface();
而此处的_strategy就是c.setStrategy传入的。algorithmInterface()即strategy接口
的行为接口，是不同的行为类必须要实现的。
(八) Mediator模式
用一个中介对象来封装一系列关于对象的交互行为.mediator其实是在交互的对象
之间起解藕作用。各个对象之间的交互操作非常多;每个对象的行为操作都依赖
彼此对方,修改一个对象的行为,同时会涉及到修改很多其他对象的行为,如果使
用Mediator模式,可以使各个对象间的耦合松散,只需关心和 Mediator的关系,使多
对多的关系变成了一对多的关系,可以降低系统的复杂性,提高可修改扩展性.
Mediator模式在事件驱动类应用中比较多,例如界面设计GUI.;聊天,消息传递等,
在聊天应用中,需要有一个MessageMediator,专门负责request/reponse之间任务
的调节.MVC是J2EE的一个基本模式,View Controller是一种Mediator,它是Jsp和
服务器上应用程序间的Mediator.
(九) Interprete模式
定义语言的文法 ,并且建立一个解释器来解释该语言中的句子.一般用在有编译需求的
应用里，用的不多。如下：
Context c = new Context(); （1）
AbstractExpression ae = new
NonterminalExpression(new TerminalExpression("hello my friend!"));（2）
ae.interpret(c); （3）
AbstractExpression就是表达式的抽象接口，真正的表达式分为终结表达式和非终结两种
第（2）行生成了一个表达式，它是一个非终结表达式。传递进取的参数其实是一个终结
表达式，当然也可以是非终结表达式再嵌套终结表示式。
（3）就是调用表达器的解释行为(充当解释器)来解释ae。
c只是一个环境参数，可以传递解释时所用到的一些全局信息。
(十) Visitor模式
一般通过被访问者的accept方法解耦访问者和被访问者的关系，该模式一般作用于某个对象
群中各个对象的操作，JAVA中最常用的就是对集合的访问操作。本来有各种鲜明类型特征
的对象一旦放入后,再取出时,这些类型就消失了.那么取出来访问的时候，我们势必要通过
if else 和 instanceof来判断取出的对象类型，并进行一系列访问操作。如：
Iterator iterator = collection.iterator();
while (iterator.hasNext()) {
Object o = iterator.next();
if (o instanceof String)
System.out.println("'"+o.toString()+"'");
else if (o instanceof Float)
System.out.println(o.toString()+"f");
else
System.out.println(o.toString());
}
如果访问时的操作过程变的更复杂了，我们势必要修改上述访问的代码，
这样给人的感觉很乱。根据面向对象的开闭原则，更改了访问的过程，
{zh0}通过增加代码来体现，尽量少修改。
从被访问的对象自身的角度来考虑，对象在一个个的容器中，与其在容器外费尽心思判断对象
的类型，不如让判断交给对象本身，因为对象自己是知道自己的类型的。这里引入了accept方法。
所以我们抽象出了IVisitor和IElement两种东西，所有的被访问者都实现了IElement,其实就是
要有accept方法。而所有的访问者都实现了Ivisitor方法。不同的访问者具有各种不同的visit
的过程。这样系统的对象层次结构就清晰了。
这样对于某个元素的一次访问，代码就可以精简为concreteelement.accept(concretevisitor）。
对于不同的访问过程，也只需要实现不同的visitor。更改的代码只要一处。
