java与模式【JAVA24种设计模式】 收藏 0

别错过了！牛人大神开始讲解java和设计模式（行为模式）

和构建模式、结构模式相比较，行为模式的内容要多一些。在设计模式种，行为模式强调的是类和对象之间的交互关系。它更多强调的是，在特定的行为场景种，使用哪一种设计模式是比较合适、比较得体的。

行为模式一般认为有11种，分别是命令模式、解释器模式、迭代模式、中介模式、备忘录模式、观察者模式、责任链模式、状态模式、策略模式、模板模式和访问者模式。

1、命令模式

命令模式的本质，是把接收命令的人、执行命令的人做了一个解耦。这样，不同的命令就成了一个个独立的个体。一个比较贴切的案例就是餐馆。餐馆里面的服务员会接收各种各样的服务要求，比如来一盘炒菜、来一个汤、来一份主食。这些点菜服务都可以看成是命令。把这些命令独立出来，并且把命令匹配给对应的执行者，这就是命令模式设计的初衷了。如果要画成类图，应该是这样的，

2、解释器模式

解释器模式，比较合适拿来类比的就是编译器。每一种编程语言都有自己的文法格式，或者称之为范式。那么这些范式就是一个一个小的解释器。最简单的解释器就是int a；这种。复杂一点的解释器就是if-statement、for-statement、while-statement这种。所以，这是如果把解析的接口抽象出来，其实就是解释器模式，

3、迭代器模式

迭代器模式，这个大家用得比较多。不管是c++，还是java都有对应的案例。假设有一个vector<int>的向量数组，那么就可以生成一个对应的迭代器，即vector<int>::iterator。有了这个迭代器，就可以用来增删改查，还可以灵活匹配各种算法。

4、中介者模式

中介者模式，顾名思义，就是之前两个对象完全没有联系，必须找一个共同的中介，才能完成信息的传递工作。现实场景中的群消息就是这种机制。一个人如果需要在群里面接收到其他人发送的消息，那就必须要绑定群组这个中介才可以。还有一个例子就是房屋买卖。房东和买房者之间一般都是不认识的，房屋交易想要达成，大多数情况下都要依赖于房产中介的协调和沟通。

5、备忘录模式

有过Windows操作系统经验的同学都知道，在OS出现复杂问题的时候，一般微软都会有一个选项，就是将OS恢复到之前的某个时间点。这样没有大问题的话，系统又能重新启用，不需要重装系统了。备忘录就是这么一种模式，在不同的时间点做一个备份处理，

6、观察者模式

观察者模式是现实开发种使用比较多的一种模式 。目前前端开发中使用比较多的一种架构，vue.js就是用了观察者模式。 有了观察者模式，编写前端的同学就可以把数据和渲染做一个解耦。数据发生改变，vue.js会自动帮助渲染。同样而言，如果有用户操作了外部控件（类似于滑动条），对应的数据也会自动发生改变。用类图来表示的话，是这样一种情形，

7、责任链模式

责任链模式是很容易和现实场景联系在一起的设计模式。比如说出差需要报销发票，这个时候不同的领导额度是不一样的，比如低于300科长可以报销，低于1000部长可以报销，低于5000可能就要总经理报销了。责任链也就是这个道理，

8、状态模式

状态模式其实和状态机是一个道理。不管是软件设计，还是fpga硬件设计，状态机都是使用比较多的一种方式。状态机很容易就构建一个封闭、鲁棒的系统。而设计模式，只是告诉我们如何用面向对象的语言来构建状态模式，

9、策略模式

策略模式有点类似于算法接口。不管是什么算法，对外的抽象接口都是一样的，这样对于输入数据而言，只需要在实际使用的时候，选择对应的算法，也就是对应的策略就可以了。策略模式一般和上面谈到的迭代器模式配合使用，

10、模板模式

模板模式比较有意思。有一些产品的制作流程是比较类似的，但是制作流程需要拆分成几个步骤。在每一个步骤里面，具体实施的细节又不一样。那么这个时候，就需要将每一个步骤的接口抽象出来，同时在顶层构建一个总的制作流程。这就好比，有一个统一的模板给你参考，每一个步骤也都是约定好的，但是具体每个步骤里面做什么是需要自己定义好的，

11、访问者模式

在个人印象中，访问者模式用得很少。有这么一种场景，画画需要绘制各种物体，而画画本身又可以分为水墨、油画、素描等各种艺术形式。这时，为了实现绘画和具体物体之间的解耦，有必要设计一种模式来完成这一目的，我们可以先看一下这个类图，

上图中的element就是各种物体，visitor就是各种画画艺术。每种物体想通过具体的艺术形式呈现出来，这就需要visitor来帮忙了。element和visitor是通过入参来完成关联的，这是一种轻量耦合的方式。

12、其他

虽然一下子把行为模式的11种情形都简单描述了一下，但是个人理解和实际应用往往还是需要花费很多的时间的。一方面，不需要死记硬背，机械地去套用；另外一方面，软件工程也在快速发展，不能认为23种设计模式已经包含了所有的开发套路，实际应用中活学活用就好了。学习的目的不在于记忆，而在于使用和改进。

原文https://www.tuicool.com/articles/BRzIviA

Java设计模式——命令模式

文章目录

• 命令模式

命令模式

命令模式很好理解，举个例子，司令员下令让士兵去干件事情，从整个事情的角度来考虑，司令员的作用是，发出口令，口令经过传递，传到了士兵耳朵里，士兵去执行。这个过程好在，三者相互解耦，任何一方都不用去依赖其他人，只需要做好自己的事儿就行，司令员要的是结果，不会去关注到底士兵是怎么实现的。我们看看关系图：

Invoker是调用者（司令员），Receiver是被调用者（士兵），MyCommand是命令，实现了Command接口，持有接收对象，看实现代码：

这个很哈理解，命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开，熟悉Struts的同学应该知道，Struts其实就是一种将请求和呈现分离的技术，其中必然涉及命令模式的思想！

介绍意图：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。

主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。

何时使用：在某些场合，比如要对行为进行\”记录、撤销/重做、事务\”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将\”行为请求者\”与\”行为实现者\”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。

如何解决：通过调用者调用接受者执行命令，顺序：调用者→接受者→命令。

关键代码：定义三个角色：1、received 真正的命令执行对象 2、Command 3、invoker 使用命令对象的入口

应用实例：struts 1 中的 action 核心控制器 ActionServlet 只有一个，相当于 Invoker，而模型层的类会随着不同的应用有不同的模型类，相当于具体的 Command。

优点： 1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。

缺点：使用命令模式可能会导致某些系统有过多的具体命令类。

使用场景：认为是命令的地方都可以使用命令模式，比如： 1、GUI 中每一个按钮都是一条命令。 2、模拟 CMD。

注意事项：系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作，也可以考虑使用命令模式，见命令模式的扩展。

文章来源：撸Java源码

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com