这是目的上的不同。它们支持的也是Undo操作的不同层面，Command是对行为序列的操作，Memento是对行为状态的操作。
State状态模式（行为型模式）
一、对象状态影响对象行为
对象拥有不同的状态，往往会行使不同的行为……
二、动机（Motivation）
在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。
如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转化之间引入紧耦合？ 三、意图（Intent）
允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。 四、要点
State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。 为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。 如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。
Strategy策略模式（行为型）
一、算法与对象的耦合
对象可能经常需要使用多种不同的算法，但是如果变化频繁，会将类型变得脆弱……
二、动机（Motivation）
在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。 如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？
三、意图（Intent）
定义一系列算法，把它们一个个封装起来，并且使它们可互相替换。该模式使得算法可独立于使用它的客户而变化。 四、要点
Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换，所谓封装算法，支持算法的变化。
Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。
与State类似，如果Strategy对象没有实例变量，那么各个上下文可以共享一个Strategy对象，从而节省对象开销。
Strategy模式适用的是算法结构中整个算法的改变，而不是算法中某个部分的改变。
Template Method方法：执行算法的步骤协议是本身放在抽象类里面的，允许一个通用的算法操作多个可能实现
Strategy模式：执行算法的协议是在具体类，每个具体实现有不同通用算法来做。
Visitor访问者模式（行为型模式）
一、类层次结构的变化
类层次结构中可能经常由于引入新的操作，从而将类型变得脆弱……
二、动机
在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。 如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？ 三、意图
表示一个作用于某对象结构中的各个元素的操作。它可以在不改变各元素的类的前提下定义作用于这些元素的新的操作。 四、要点
Visitor模式通过所谓双重分发（double dispatch）来实现在不更改Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作。
所谓双重分发即Visitor模式中间包括了两个多态分发（注意其中的多态机制）：第一个为accept方法的多态辨析；第二个为visit方法的多态辨析。
Visitor模式的最大缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变。因此Visitor模式适用于“Element类层次结构稳定，而其中的操作却经常面临频繁改动”。 设计模式其实是一种堵漏洞的方式，但是没有一种设计模式能够堵完所有的漏洞，即使是组合各种设计模式也是一样。每个设计模式都有漏洞，都有它们解决不了的情况或者变化。每一种设计模式都假定了某种变化，也假定了某种不变化。Visitor模式假定的就是操作变化，而Element类层次结构稳定。
总结
创建型模式
Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。 Factory Method，Abstract Factory，Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。
如果遇到“易变类”，起初的设计通常从Factory Method开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（Abstract Factory，Builder，Prototype）。
结构型模式
Adapter模式注重转换接口，将不吻合的接口适配对接（适合于旧系统） Bridge模式注重分离接口与其实现，支持多维度变化
Composite模式注重统一接口，将“一对多”的关系转化为“一对一”的关系 Decorator模式注重稳定接口，在此前提下为对象扩展功能
Facade模式注重简化接口，简化组件系统与外部客户程序的依赖关系 Flyweight模式注重保留接口，在内部使用共享技术对对象存储进行优化 Proxy模式注重假借接口，增加间接层来实现灵活控制
行为型模式
Template Method模式封装算法结构，支持算法子步骤变化 Strategy模式注重封装算法，支持算法的变化
State模式注重封装与状态相关的行为，支持状态的变化 Memento模式注重封装对象状态变化，支持状态保存/恢复 Mediator模式注重封装对象间的交互，支持对象交互的变化
Chain Of Responsibility模式注重封装对象责任，支持责任的变化 Command模式注重将请求封装为对象，支持请求的变化 Iterator模式注重封装集合对象内部结构，支持集合的变化
Interpreter模式注重封装特定领域变化，支持领域问题的频繁变化 Observer模式注重封装对象通知，支持通信对象的变化
Visitor模式注重封装对象操作变化，支持在运行时为类层次结构动态添加新的操作 模式之间的关系图