JAVA设计模式总结之23种设计模式(2)

所谓模板方法模式就是在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

模板方法模式就是基于继承的代码复用技术的。在模板方法模式中，我们可以将相同部分的代码放在父类中，而将不同的代码放入不同的子类中。也就是说我们需要声明一个抽象的父类，将部分逻辑以具体方法以及具体构造函数的形式实现，然后声明一些抽象方法让子类来实现剩余的逻辑，不同的子类可以以不同的方式来实现这些逻辑。所以模板方法的模板其实就是一个普通的方法，只不过这个方法是将算法实现的步骤封装起来的。

模板方法模式包含如下角色：

AbstractClass: 抽象类

ConcreteClass: 具体子类

15.策略模式

我们知道一件事可能会有很多种方式来实现它，但是其中总有一种最高效的方式，在软件开发的世界里面同样如此，我们也有很多中方法来实现一个功能，但是我们需要一种简单、高效的方式来实现它，使得系统能够非常灵活，这就是策略模式。

策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。策略模式定义了算法族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。策略模式---定义了算法族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。

*策略（strategy）模式与模板方法（template method）模式的区别：策略模式实现了完整的算法，各个算法之间可以互相替换。算法1提出的是动态的博弈模型，该模式可能在进行实际的攻击策略时会与预期的攻击策略出现一定的差错或者是不对应的情况，导致在又一个新的节点上采取新的动态博弈的措施，所以算法1可以在攻击的意图发生变化的时候仍旧计算出最佳的攻击集合，并且除此之外，算法1提出的方法能够对整个的状态空间进行全面的博弈局势的掌握，由此便可以推测出最优化的防御措施。策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。

所以可以这样描述这一系列策略算法：策略算法是相同行为的不同实现。策略模式实现了算法和算法实用类的解耦，算法之间也消除了耦合，使得算法的替换变得灵活方便。行为分析引擎是实现主动防御的核心模块，本文通过对朴素贝叶斯分类算法和行为加权求和策略的研究，挖掘这两种主流的行为分析策略的优点和不足，提出了基于特征加权的贝叶斯行为分析算法，从理论上分析了其可行性，构建了wfb模型，并对权值的选取给出了说明，最后给出了此算法应用于摆渡木马防御时的处理方法。

策略模式包含如下角色：

Context: 环境类

Strategy: 抽象策略类

ConcreteStrategy: 具体策略类

16.状态模式

可以是final对象，但对象的行为不会对其状态产生任何影响，比如string的substring就是new一个string对象各种number类型如biginteger和bigdecimal等大数据类型都是不可变的，但是同为number子类型的atomicinteger和atomiclong则并非不可变我觉得原因是它里面状态对象时unsafe对象，所做的操作都是cas操作，可以保证原子性。实例化后的对象被封装在beanwrapper对象中，并且此时对象仍然是一个原生的状态，并没有进行依赖注入。13.状态模式：状态模式允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。

所以状态模式就是允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。

在状态模式中我们可以减少大块的if…else语句，它是允许态转换逻辑与状态对象合成一体，但是减少if…else语句的代价就是会换来大量的类，所以状态模式势必会增加系统中类或者对象的个数。

同时状态模式是将所有与某个状态有关的行为放到一个类中移动设计模式库，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。但是这样就会导致系统的结构和实现都会比较复杂，如果使用不当就会导致程序的结构和代码混乱，不利于维护。

状态模式包含如下角色：

Context: 环境类

State: 抽象状态类

ConcreteState: 具体状态类

17.观察者模式

何谓观察者模式？观察者模式定义了对象之间的一对多依赖关系，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并且自动更新。

在这里，发生改变的对象称之为观察目标，而被通知的对象称之为观察者。一个观察目标可以对应多个观察者，而且这些观察者之间没有相互联系，所以么可以根据需要增加和删除观察者，使得系统更易于扩展。所以观察者提供了一种对象设计，让主题和观察者之间以松耦合的方式结合。

观察者模式包含如下角色：

Subject: 目标

ConcreteSubject: 具体目标

Observer: 观察者

ConcreteObserver: 具体观察者

18.备忘录模式

后悔药人人都想要，但是事实却是残酷的，根本就没有后悔药可买，但是也不仅如此，在软件的世界里就有后悔药！备忘录模式就是一种后悔药，它给我们的软件提供后悔药的机制，通过它可以使系统恢复到某一特定的历史状态。

所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。它实现了对信息的封装，使得客户不需要关心状态保存的细节。保存就要消耗资源，所以备忘录模式的缺点就在于消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。

备忘录模式包含如下角色：

Originator: 原发器

Memento: 备忘录

Caretaker: 负责人

19.中介者模式

租房各位都有过的经历吧！在这个过程中中介结构扮演着很重要的角色，它在这里起到一个中间者的作用，给我们和房主互相传递信息。在外面软件的世界里同样需要这样一个中间者。在我们的系统中有时候会存在着对象与对象之间存在着很强、复杂的关联关系，如果让他们之间有直接的联系的话，必定会导致整个系统变得非常复杂，而且可扩展性很差！在前面我们就知道如果两个类之间没有不必彼此通信，我们就不应该让他们有直接的关联关系，如果实在是需要通信的话，我们可以通过第三者来转发他们的请求。同样，这里我们利用中介者来解决这个问题。

所谓中介者模式就是用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。在中介者模式中，中介对象用来封装对象之间的关系，各个对象可以不需要知道具体的信息通过中介者对象就可以实现相互通信。它减少了对象之间的互相关系，提供了系统可复用性，简化了系统的结构。

sta套间一个套间如果是sta，那么那个套间有且只有一个线程和其关联，有多个对象或没有对象和其关联，就像有多个线程和一个进程关联一样，也就是说套间那个结构和某个线程及多个对象之间有关系，关系具体是什么由com说得算，幸运的是com正是按照上面的线程模型来定义互相之间关系的。uml的历史ooad面向对象的分析设计语言booth oose omt1997年uml一统天下第三部分：uml的概览1、 鸟瞰umluml各种图形的名称与作用uml如何用于开发过程简略介绍用于描述系统结构：用例图：需求捕获，测试依据类图：静态系统架构对象图：对象之间的关联构件图：构件之间的关联部署图：构件的物理部署用于描述系统行为：顺序图：不活user case 在某个时间场景上时间执行顺序协作图：强调对象之间的写作顺序图与协作图之间可以互相转换，而其中的信息不会丢失状态图：描述关键类生命周期的转化活动图：流程图，描述某个方法或user case的执行过程。当与某持久对象关联的session被关闭后,该持久对象转变为托管对象.当托管对象被重新关联到session上时,合并再次转变成持久对象,托管对象拥有的标别值。

Mediator: 抽象中介者

ConcreteMediator: 具体中介者

Colleague: 抽象同事类

ConcreteColleague: 具体同事类

20.迭代器模式

*迭代器（iterator）模式把元素之间游走的任务交给了迭代器，而不是聚合对象。在设计中使用迭代器的影响是明显的：如果你有一个统一的方法访问聚合中的每一个对象，你就可以编写多态的代码和这些聚合搭配使用，如同前面的printmenu()方法一样，只要有了迭代器这个方法，根本不管菜单项究竟是由数组还是由arraylist（或者其他能创建迭代器的东西）来保存的。上述代码首先通过array的getenumerator方法来获取array的一个“迭代器”，然后通过“迭代器”的movenext方法进行依次遍历，而这“迭代器”实际上就是之前那个稍显奇怪的ienumerator类型。

何为迭代器模式？所谓迭代器模式就是提供一种方法顺序访问一个聚合对象中的各个元素，而不是暴露其内部的表示。迭代器模式是将迭代元素的责任交给迭代器，而不是聚合对象，我们甚至在不需要知道该聚合对象的内部结构就可以实现该聚合对象的迭代。

迭代器模式让我们能遍历聚合内没一个元素,而又不暴露其内部表示.。在设计中使用迭代器的影响是明显的：如果你有一个统一的方法访问聚合中的每一个对象，你就可以编写多态的代码和这些聚合搭配使用，如同前面的printmenu()方法一样，只要有了迭代器这个方法，根本不管菜单项究竟是由数组还是由arraylist（或者其他能创建迭代器的东西）来保存的。这个目标，可以是collection集合或者数组，如果遍历collection集合，在遍历过程中还需要对元素进行操作，比如删除，需要使用迭代器。

迭代器模式包含如下角色：

Iterator: 抽象迭代器

ConcreteIterator: 具体迭代器

Aggregate: 抽象聚合类

ConcreteAggregate: 具体聚合类

21.解释器模式

解释器模式(interpreter):给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。十五、interpreter，解释器模式：给定一个语言，定义他的文法的一个表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。

解释器模式包含如下角色：

AbstractExpression: 抽象表达式

TerminalExpression: 终结符表达式

NonterminalExpression: 非终结符表达式

Context: 环境类

Client: 客户类

22.命令模式

oo模式：命令模式——将请求封装成对象，这可以让你使用不同的请求，队列，或者日志请求来参数化其他对象。命令（command）模式：将“请求”封装成对象，以便使用请求、队列或日志来参数化其它对象。我们知道一个命令对象通过在特定接收者上绑定一组动作来封装一个请求，要达到这一点，命令对象将动作和接收者包进对象中。

命令模式可以将请求的发送者和接收者之间实现完全的解耦，发送者和接收者之间没有直接的联系，发送者只需要知道如何发送请求命令即可，其余的可以一概不管，甚至命令是否成功都无需关心。同时我们可以非常方便的增加新的命令，但是可能就是因为方便和对请求的封装就会导致系统中会存在过多的具体命令类。

命令模式包含如下角色：

Command: 抽象命令类

ConcreteCommand: 具体命令类

Invoker: 调用者

Receiver: 接收者

Client:客户类

23.责任链模式

请求在这个链上传递，直到链上的某一个对象决定处理此请求。处理完成后，它会交给下一个过滤器处理，这样，客户的请求在过滤链里逐个处理，直到请求发送到目标为止。由actionform和javabean组成，其中actionform用于将用户的请求参数封装成actionform对象，该对象被actionservlet转发给action，action根据actionform里面的请求参数处理用户的请求。

十二、china of responsibility，职责链模式：使多个对象都有机会处理请求，从而避免请求的送发者和接收者之间的耦合关系。各个处理对象通过setsuccessor设置下一个处理对象，当自己无法处理时就将请求交给下一个对象，于是形成职责链，从而实现了请求和处理者的解耦，可避免大量的判断语句，也增加了职责链的灵活性（可动态修改）。发送这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以再不影响客户端的情况下动态地重新组织链和分配责任。

职责链模式包含如下角色：

Handler: 抽象处理者

ConcreteHandler: 具体处理者

Client: 客户类

五、如何学习设计模式

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-110049-2.html