知识大全设计模式分解java(6)

Posted 2022-07-18 状态

篇首语：盛年不重来，一日难再晨，及时当勉励，岁月不待人。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全设计模式分解java(6)相关的知识，希望对你有一定的参考价值。

　　/** */

　　行为模式 Command

　　Command模式是最让我疑惑的一个模式我在阅读了很多代码后

　　才感觉隐约掌握其大概原理我认为理解设计模式最主要是掌握起原理构造

　　这样才对自己实际编程有指导作用 Command模式实际上不是个很具体

　　规定很多的模式正是这个灵活性让人有些confuse

　　Command定义

　　不少Command模式的代码都是针对图形界面的它实际就是菜单命令

　　我们在一个下拉菜单选择一个命令时然后会执行一些动作

　　将这些命令封装成在一个类中然后用户(调用者)再对这个类进行操作这就是Command模式

　　换句话说本来用户(调用者)是直接调用这些命令的如菜单上打开文档(调用者)

　　就直接指向打开文档的代码使用Command模式就是在这两者之间增加一个中间者

　　将这种直接关系拗断同时两者之间都隔离基本没有关系了

　　显然这样做的好处是符合封装的特性降低耦合度

　　Command是将对行为进行封装的典型模式

　　Factory是将创建进行封装的模式

　　从Command模式我也发现设计模式一个通病 :好象喜欢将简单的问题复杂化

　　喜欢在不同类中增加第三者当然这样做有利于代码的健壮性可维护性还有复用性

　　如何使用?

　　具体的Command模式代码各式各样因为如何封装命令不同系统有不同的做法

　　下面事例是将命令封装在一个Collection的List中任何对象一旦加入List中实际上装入了一个封闭的黑盒中

　　对象的特性消失了只有取出时才有可能模糊的分辨出:

　　典型的Command模式需要有一个接口接口中有一个统一的方法这就是将命令/请求封装为对象 :

　　public interface Command

　　public abstract void execute ( );

　　具体不同命令/请求代码是实现接口Command 下面有三个具体命令

　　public class Engineer implements Command

　　public void execute( )

　　//do Engineer s mand

　　public class Programmer implements Command

　　public void execute( )

　　//do programmer s mand

　　public class Politician implements Command

　　public void execute( )

　　//do Politician s mand

　　按照通常做法我们就可以直接调用这三个Command 但是使用Command模式

　　我们要将他们封装起来扔到黑盒子List里去:

　　public class producer

　　public static List produceRequests()

　　List queue = new ArrayList();

　　queue add( new DomesticEngineer() );

　　queue add( new Politician() );

　　queue add( new Programmer() );

　　return queue;

　　这三个命令进入List中后已经失去了其外表特征以后再取出

　　也可能无法分辨出谁是Engineer 谁是Programmer了看下面如何调用Command模式:

　　public class TestCommand

　　public static void main(String[] args)

　　List queue = Producer produceRequests();

　　for (Iterator it = erator(); it hasNext(); )

　　//取出List中东东其他特征都不能确定只能保证一个特征是 %正确

　　// 他们至少是接口Command的儿子所以强制转换类型为接口Command

　　((Command)it next()) execute();

　　由此可见调用者基本只和接口打交道不合具体实现交互这也体现了一个原则

　　面向接口编程这样以后增加第四个具体命令时就不必修改调用者TestCommand中的代码了

　　理解了上面的代码的核心原理在使用中就应该各人有自己方法了特别是在如何分离调用者和具体命令上

　　有很多实现方法上面的代码是使用从List过一遍的做法这种做法只是为了演示

　　使用Command模式的一个好理由还因为它能实现Undo功能

　　每个具体命令都可以记住它刚刚执行的动作并且在需要时恢复

　　Command模式在界面设计中应用广泛 Java的Swing中菜单命令都是使用Command模式

　　/** */

　　行为模式 State

　　State的定义: 不同的状态不同的行为;或者说每个状态有着相应的行为

　　何时使用?

　　State模式在实际使用中比较多适合状态的切换因为我们经常会使用If elseif else 进行状态切换

　　如果针对状态的这样判断切换反复出现我们就要联想到是否可以采取State模式了

　　不只是根据状态也有根据属性如果某个对象的属性不同对象的行为就不一样

　　这点在数据库系统中出现频率比较高我们经常会在一个数据表的尾部

　　加上property属性含义的字段用以标识记录中一些特殊性质的记录

　　这种属性的改变(切换)又是随时可能发生的就有可能要使用State

　　是否使用?

　　在实际使用类似开关一样的状态切换是很多的但有时并不是那么明显取决于你的经验和对系统的理解深度

　　这里要阐述的是开关切换状态和一般的状态判断是有一些区别的

　　一般的状态判断也是有 if elseif结构例如:

　　if (which== ) state= hello ;

　　else if (which== ) state= hi ;

　　else if (which== ) 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了

　　请看下例:

　　public class Context

　　private Color state=null;

　　public void push()

　　//如果当前red状态就切换到blue

　　if (state==Color red) state=Color blue;

　　//如果当前blue状态就切换到green

　　else if (state==Color blue) state=Color green;

　　//如果当前black状态就切换到red

　　else if (state==Color black) state=Color red;

　　//如果当前green状态就切换到black

　　else if (state==Color green) state=Color black;

　　Sample sample=new Sample(state);

　　sample operate();

　　public void pull()

　　//与push状态切换正好相反

　　if (state==Color green) state=Color blue;

　　else if (state==Color black) state=Color green;

　　else if (state==Color blue) state=Color red;

　　else if (state==Color red) state=Color black;

　　Sample sample =new Sample (state);

　　sample operate();

　　在上例中我们有两个动作push推和pull拉这两个开关动作改变了Context颜色

　　至此我们就需要使用State模式优化它

　　另外注意:但就上例 state的变化只是简单的颜色赋值这个具体行为是很简单的

　　State适合巨大的具体行为因此在就本例实际使用中也不一定非要使用State模式

　　这会增加子类的数目简单的变复杂

　　例如: 银行帐户经常会在Open 状态和Close状态间转换

　　例如: 经典的TcpConnection Tcp的状态有创建侦听关闭三个

　　并且反复转换其创建侦听关闭的具体行为不是简单一两句就能完成的适合使用State

　　例如:信箱POP帐号会有四种状态 start HaveUsername Authorized quit

　　每个状态对应的行为应该是比较大的适合使用State

　　例如:在工具箱挑选不同工具可以看成在不同工具中切换适合使用State

　　如具体绘图程序用户可以选择不同工具绘制方框直线曲线这种状态切换可以使用State

　　如何使用

　　State需要两种类型实体参与:

　　 state manager 状态管理器就是开关如上面例子的Context实际就是一个state manager

　　在state manager中有对状态的切换动作

　　用抽象类或接口实现的父类不同状态就是继承这个父类的不同子类

　　以上面的Context为例我们要修改它建立两个类型的实体

　　第一步: 首先建立一个父类:

　　public abstract class State

　　public abstract void handlepush(Context c);

　　public abstract void handlepull(Context c);

　　public abstract void getcolor();

　　父类中的方法要对应state manager中的开关行为在state manager中

　　本例就是Context中有两个开关动作push推和pull拉

　　那么在状态父类中就要有具体处理这两个动作:handlepush() handlepull();

　　同时还需要一个获取push或pull结果的方法getcolor()

　　下面是具体子类的实现:

　　public class BlueState extends State

　　public void handlepush(Context c)

　　//根据push方法如果是blue状态的切换到green ;

　　c setState(new GreenState());

　　public void handlepull(Context c)

　　//根据pull方法如果是blue状态的切换到red ;

　　c setState(new RedState());

　　public abstract void getcolor() return (Color blue)

　　同样其他状态的子类实现如blue一样

　　第二步: 要重新改写State manager 也就是本例的Context:

　　public class Context

　　private Sate state=null; //我们将原来的 Color state 改成了新建的State state;

　　//setState是用来改变state的状态使用setState实现状态的切换

　　pulic void setState(State state)

　　this state=state;

　　public void push()

　　//状态的切换的细节部分在本例中是颜色的变化已经封装在子类的handlepush中实现这里无需关心

　　state handlepush(this);

　　//因为sample要使用state中的一个切换结果使用getColor()

　　Sample sample=new Sample(state getColor());

　　sample operate();

　　public void pull()

　　state handlepull(this);

　　Sample sample =new Sample (state getColor());

　　sample operate();

　　至此我们也就实现了State的refactorying过程

　　以上只是相当简单的一个实例在实际应用中 handlepush或handelpull的处理是复杂的

　　/** */

　　行为模式 Strategy

　　Strategy是属于设计模式中对象行为型模式主要是定义一系列的算法把这些算法一个个封装成单独的类

　　Stratrgy应用比较广泛比如公司经营业务变化图

　　可能有两种实现方式一个是线条曲线一个是框图(bar) 这是两种算法可以使用Strategy实现

　　这里以字符串替代为例有一个文件我们需要读取后希望替代其中相应的变量

　　然后输出关于替代其中变量的方法可能有多种方法这取决于用户的要求所以我们要准备几套变量字符替代方案

　　首先我们建立一个抽象类RepTempRule 定义一些公用变量和方法:

　　public abstract class RepTempRule

　　protected String oldString= ;

　　public void setOldString(String oldString)

　　this oldString=oldString;

　　protected String newString= ;

　　public String getNewString()

　　return newString;

　　public abstract void replace() throws Exception;

　　在RepTempRule中有一个抽象方法abstract需要继承明确这个replace里其实是替代的具体方法

　　我们现在有两个字符替代方案

　　将文本中aaa替代成bbb;

　　将文本中aaa替代成ccc;

　　对应的类分别是RepTempRuleOne RepTempRuleTwo

　　public class RepTempRuleOne extends RepTempRule

　　public void replace() throws Exception

　　//replaceFirst是jdk 新特性

　　newString=oldString replaceFirst( aaa bbbb )

　　System out println( this is replace one );

　　public class RepTempRuleTwo extends RepTempRule

　　public void replace() throws Exception

　　newString=oldString replaceFirst( aaa ccc )

　　System out println( this is replace Two );

　　第二步我们要建立一个算法解决类用来提供客户端可以自由选择算法

　　public class RepTempRuleSolve

　　private RepTempRule strategy;

　　public RepTempRuleSolve(RepTempRule rule)

　　this strategy=rule;

　　public String getNewContext(Site site String oldString)

　　return strategy replace(site oldString);

　　public void changeAlgorithm(RepTempRule newAlgorithm)

　　strategy = newAlgorithm;

　　调用如下:

　　public class test

　　public void testReplace()

　　//使用第一套替代方案

　　RepTempRuleSolve solver=new RepTempRuleSolve(new RepTempRuleSimple());

　　solver getNewContext(site context);

　　//使用第二套

　　solver=new RepTempRuleSolve(new RepTempRuleTwo());

　　solver getNewContext(site context);

　　我们达到了在运行期间可以自由切换算法的目的

　　实际整个Strategy的核心部分就是抽象类的使用使用Strategy模式可以在用户需要变化时修改量很少而且快速

　　Strategy和Factory有一定的类似 Strategy相对简单容易理解并且可以在运行时刻自由切换

　　Factory重点是用来创建对象

　　Strategy适合下列场合:

　　以不同的格式保存文件;

　　以不同的算法压缩文件;

　　以不同的算法截获图象;

　　以不同的格式输出同样数据的图形比如曲线或框图bar等

　　/** */

　　行为模式 Mediator

　　Mediator定义:

　　用一个中介对象来封装一系列关于对象交互行为

　　为何使用Mediator?

　　各个对象之间的交互操作非常多;每个对象的行为操作都依赖彼此对方

　　修改一个对象的行为同时会涉及到修改很多其他对象的行为如果使用Mediator模式

　　可以使各个对象间的耦合松散只需关心和 Mediator的关系

　　使多对多的关系变成了一对多的关系可以降低系统的复杂性提高可修改扩展性

　　如何使用?

　　首先有一个接口用来定义成员对象之间的交互联系方式:

　　public interface Mediator

　　Meiator具体实现真正实现交互操作的内容:

　　public class ConcreteMediator implements Mediator

　　//假设当前有两个成员

　　private ConcreteColleague colleague = new ConcreteColleague ();

　　再看看另外一个参与者:成员因为是交互行为都需要双方提供一些共同接口

　　这种要求在Visitor Observer等模式中都是相同的

　　public class Colleague

　　private Mediator mediator;

　　public Mediator getMediator()

　　return mediator;

　　public void setMediator( Mediator mediator )

　　diator = mediator;

　　public class ConcreteColleague

　　每个成员都必须知道Mediator 并且和 Mediator联系而不是和其他成员联系

　　至此 Mediator模式框架完成可以发现Mediator模式规定不是很多

　　大体框架也比较简单但实际使用起来就非常灵活

　　Mediator模式在事件驱动类应用中比较多例如界面设计GUI ;聊天消息传递等

　　在聊天应用中需要有一个MessageMediator 专门负责request/reponse之间任务的调节

　　MVC是J EE的一个基本模式 View Controller是一种Mediator 它是Jsp和服务器上应用程序间的Mediator

　　/** */

　　行为模式 Interpreter

　　Interpreter定义:

　　定义语言的文法并且建立一个解释器来解释该语言中的句子

　　Interpreter似乎使用面不是很广它描述了一个语言解释器是如何构成的

　　在实际应用中我们可能很少去构造一个语言的文法我们还是来简单的了解一下:

　　首先要建立一个接口用来描述共同的操作

　　public interface AbstractExpression

　　void interpret( Context context );

　　再看看包含解释器之外的一些全局信息

　　public interface Context

　　AbstractExpression的具体实现分两种:终结符表达式和非终结符表达式:

　　public class TerminalExpression implements AbstractExpression

　　public void interpret( Context context )

　　对于文法中没一条规则非终结符表达式都必须的:

　　public class NonterminalExpression implements AbstractExpression

　　private AbstractExpression successor;

　　public void setSuccessor( AbstractExpression successor )

　　this successor = successor;

　　public AbstractExpression getSuccessor()

　　return successor;

　　public void interpret( Context context )

　　/** */

　　行为模式 Visitor

　　Visitor定义

　　作用于某个对象群中各个对象的操作它可以使你在不改变这些对象本身的情况下定义作用于这些对象的新操作

　　在Java中 Visitor模式实际上是分离了collection结构中的元素和对这些元素进行操作的行为

　　为何使用Visitor?

　　Java的Collection(包括Vector和Hashtable)是我们最经常使用的技术

　　可是Collection好象是个黑色大染缸本来有各种鲜明类型特征的对象一旦放入后再取出时这些类型就消失了

　　那么我们势必要用If来判断如:

　　Iterator iterator = erator()

　　while (iterator hasNext())

　　Object o = iterator next();

　　if (o instanceof Collection)

　　messyPrintCollection((Collection)o);

　　else 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());

　　在上例中我们使用了 instanceof来判断 o的类型

　　很显然这样做的缺点代码If else if 很繁琐我们就可以使用Visitor模式解决它

　　如何使用Visitor?

　　针对上例我们设计一个接口visitor访问者:

　　public interface Visitor

　　public void visitCollection(Collection collection);

　　public void visitString(String string);

　　public void visitFloat(Float float);

　　在这个接口中将我们认为Collection有可能的类的类型放入其中

　　有了访问者我们需要被访问者被访问者就是我们Collection的每个元素Element

　　我们要为这些Element定义一个可以接受访问的接口(访问和被访问是互动的

　　只有访问者被访问者如果表示不欢迎访问者就不能访问)

　　我们定义这个接口叫Visitable 用来定义一个Accept操作也就是说让Collection每个元素具备可访问性

　　public interface Visitable

　　public void accept(Visitor visitor);

　　好了有了两个接口我们就要定义他们的具体实现(Concrete class):

　　public class ConcreteElement implements Visitable

　　private String value;

　　public ConcreteElement(String string)

　　value = string;

　　//定义accept的具体内容这里是很简单的一句调用

　　public void accept(Visitor visitor)

　　visitor visitString(this);

　　再看看访问者的Concrete实现:

　　public class ConcreteVisitor implements Visitor

　　//在本方法中我们实现了对Collection的元素的成功访问

　　public void visitCollection(Collection collection)

　　Iterator iterator = erator()

　　while (iterator hasNext())

　　Object o = iterator next();

　　if (o instanceof Visitable)

　　((Visitable)o) accept(this);

　　public void visitString(String string)

　　System out println( +string+ );

　　public void visitFloat(Float float)

　　System out println(float toString()+ f );

　　在上面的visitCollection我们实现了对Collection每个元素访问

　　只使用了一个判断语句只要判断其是否可以访问

　　至此我们完成了Visitor模式基本架构

　　使用Visitor模式的前提

　　对象群结构中(Collection) 中的对象类型很少改变也就是说访问者的身份类型很少改变

　　如上面中Visitor中的类型很少改变如果需要增加新的操作比如上例中我们在ConcreteElement具体实现外

　　还需要新的ConcreteElement ConcreteElement

　　可见使用Visitor模式是有前提的在两个接口Visitor和Visitable中

　　确保Visitor很少变化变化的是Visitable 这样使用Visitor最方便

　　如果Visitor也经常变化也就是说对象群中的对象类型经常改变一般建议是

　　不如在这些对象类中逐个定义操作但是Java的Reflect技术解决了这个问题

cha138/Article/program/Java/gj/201311/27375

知识大全 设计模式分解java(6)

知识大全设计模式分解java(6)