状态模式和策略模式很像，他们都为变化设计了一个抽象类，然后派生出一系列的子类，用一个属性保存对这个子类的引用，通常通过构造函数对这个属性初始化，然后在类中一直调用这个属性的相关方法进行操作。然后他们都通过改变这个属性的值，将它指向其它子类，从而改变超类的方法的表现。区别在于策略模式的set()方法是公开的接口，留给用户主观地去改变属性。而状态模式不是，状态模式会初始化属性，但属性以后如何改变，是通过内置的逻辑进行操控的，不提成set()方法给用户主动地改变。也就是说，策略模式是让用户去改属性，而策略模式是根据类的状态，自动地变化属性。

   具体来说，状态模式会在一系列的子类中，根据当前子类的状态，给自己的方法设置相关的set（）方法，改变主体类的相关属性。主体类的相关属性一改，再次调用同名的方法时，因为属性已经不同了，调用的系列子类的方法也就不同了。

   工厂方法模式一个很关键的东西就是工厂方法！如果我们的对象具体要实化哪一个类不确定，但是这个对象一定会在接下来的流程中实现某些方法，我们可以用工厂方法来返回一个对象，然后对这个对象来引用它的方法。其实工厂方法是个抽象方法，在超类中并不会真的去实现，那么工厂方法在超类中其实只算是一个抽象的对象，它的具体返回值需要子类里定义。我们在定义超类的子类时，需要实现工厂方法，并在这个工厂方法中完成具体对象的实例化，并将它做为返回值返回。

    也就是说，超类中提前虚拟了一个返回值，对返回值进行了操做，完成了超类的框架。在工厂方法模式中，我们定义一个有工厂方法的超类，然后对这个超类进行派生，生成一群工厂方法返回不同产品对象的子类。而我们在使用的时候，也不会直接使用超类进行实例化，只会对具体的子类进行实例化。如果有新的扩展，我们直接继承一下超类，然后定义一下工厂方法，就可以拿这个新的类去实例化了。这样的做法很好地尊寻了开放－关闭原则。

     简单工厂虽然很好用，却没有尊寻开放－关闭原则。如果我们的系统比较复杂，以后很可能会扩展的话，尽量选用工厂方法模式而不要使用简单工厂。

中介者模式其实是在两个对象之间建立一个中间对象，两个对象都只认识中间对象，两个对象之间的通信完全通过中间对象实现，它们互相不认识，从而让两个对象之间解耦。

具体来说，两个对象的构造函数都需要传入中介者对象，然后，两个对象中的通信方法其实都是对中介对象通信方法的调用。中介对象的通信方法要负责所有的逻辑判断，自己忙死了，从而让另两个对象可以直接和对方接触。中介对象就像个管家一样。

职责链模式：使多个对象都有机会处理请求，从而避免请求发送者和接收者之间的耦合关系。将接收对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。当客户提交一个请求时，请求一定是从链的开始处提交，但是具体到链的哪一个环节进行处理，客户并不知道。且链中的对象也并不知道链的结构。结果是职责链可简化对象的相互链接，它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用。这就大大降低了耦合度了。

职责链模式只有一个角色，处理类。这个类里有一个属性，用于保存这个处理类的后继者，也就链中的下一环。有两个方法，一个用于设置设置后继者，通过给方法传入后继者对象，赋值给处理类的后继者属性。另一个方法就是处理方法。处理方法中会有一个断送逻辑，如果满足这个判断逻辑，那么对请求进行处理，如果不满足，就调用处理类后继者的处理方法，把责任推给后继者。后继者直接就运行了处理方法，它的后继者又在哪里指定的呢？其实职责链模式在开始处理请求之前，会把所有的处理类实例化出来，然后调用设置后继者方法，在一开始就确定好所有处理类之间的链接关系。然后，再调用链接中第一环的处理方法，开始对请求进行传递。

命令模式中有三个角色，第一个是命令的执行者，这个类中定义好各种方法，只负责做事情（根据传递过来的命令调用不同方法完成操作)，是个典型的model，本身并不加任何control的逻辑。第二个角色是命令。命令类会有一个抽象的接口，这个接口派生出一个个具体的命令类，每个具体命令类只负责一个逻辑，它的构造函数要传入一个参数，这个参数就是执行者，将这个参数通过构造函数传给命令类，让命令类知道让谁去执行。命令类中会有一个方法，用于让执行者开始执行这个命令类的指定动作，也就是根据这个命令类的职责去调用执行者的相关方法。第三个角色是服务员。服务员有一个数组类型的属性，用于保存命令对象。然后会有三个方法，一个用于添加命令对象，这个方法需要通过传入一个命令对象类型的参数，来实现对命令数组的添加。然后是删除命令方法，这个方法也要传入一个命令对象类型的参数，来实现对指定命令的删除。最后一个方法是通知执行者开始工作的方法。这个方法通过遍历命令对象数组，来逐一调用命令对象的执行方法，间接让命令执行者一一执行相关的命令（执行相关方法）。

命令模式可以让“动作的请求者”从“动作的执行者”对象中解耦。

命令模式的优点：

1.它能较容易地设计一个命令队列;

2.允许接收请求的一方决定是否要否决请求;

3.在需要的情况下，可以容易地将命令记入日志;

4.可以容易地实现对请求的撤消和重做;

5.由于加进新的具体命令类不影响其它的类，因此增加新的具体命令类很容易;

6.命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开。可以让类的单一职责更明确，充分解耦。

　如果实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少它们之间的耦合。在发现我们需要多角度去分类实现对象，而只用继承会造成大量类的增加，不能满足开发——封闭原则时，就应该要考虑桥接模式了。

　桥接模式中分把系统中的角色按照不同角度去抽象成多个类，每个角度是个独立的类。每个角度可以派生出自己的具体类，然后不同角度的各个类通过组合的方式来实现不同角度功能上的实现，而不是通过在子类里利用得载实现。具体来说，组合在技术上，就是通过在一个类中设置一个属性，和一个方法，方法通过传参来设置这个类的这个属性的值，而传递的参数就是另一个角度的具体类。

　多用组合，少用继续，可以让程序更具有灵活性，并且封装良好。

如果想要一个全局统一的对象，可以把这个对象设为全局变量。如果想要实现一个类只能实例化一次，那么就需要用到单例模式了。

单例模式就是将单例类的构造函数设为私有，然后通过设置一个静态方法，静态方法中对这个类是否实例化做判断，如果没有实例化过，就new一个单例类的实例，然后做为这个静态方法的返回值返回。因为构造函数私有，所以不用通过new直接实例化，一定要调用静态方法来间接实例化。而静态方法中设置判断，就可以要求每个需要实例化的请求都必须通过这个判断。

单例模式需要考虑的问题是多线程时，如何避免实例化的瞬间有多个纯程同时进行了静态方法的调用，从而实例化出多个实例。

备忘录模式中有三个角色：备忘对象，备忘记录，备忘记录箱。备忘对象有备份方法和还原备份方法，其中备份方法要调用备忘记录类的构造函数，将备忘对象中需要保存的属性做为参数传进去，返回备忘记录类的实例。而备忘对象的备份方法是由备忘记录箱类的记录方法来调用的，备忘记录箱类用一个数组型的属性保存备忘对象类的备份方法返回的备忘记录实例。然后，备忘对象的还原备份方法需要传入一个备忘记录实例，根据这个实例中保存的相关属性，对备忘对象属性进行斌值，也就是实现了还原。这个传入的备忘记录实例就是备忘记录箱中用于保存备忘对象实例的相关属性了。

这是个好模式，以后做游戏可以用这个模式还实现存档了，哈。

　　适配器模式中有三个角色，一个是目标类，一个是原始类，还有一个是适配器类。原始类和目标类接口是不一样的，如果我们想让原始类实现目标类的接口，同时不改变原始类的话，就可以通过适配器类做到。

　　适配器类定义和目标类一样的接口，也就是方法，如此一来，表面看起来就和目标类的用法一致，然后在适配器类的方法中调用原始类的方法，从而实现将原始类适配成目标类的目的。也就是说，适配器类表面看起来用法和目标类一样，实际上类里的方法完全不一样。

　当一个对象的改变需要同时改变其它多个对象，特别是不知道具体有多少对象时，可以考虑使用观察者模式。

　观察者模式中有两个角色，一个是通知者，一个是被通知者。通知者类必须有三个方法，添加被通知者方法，删除被通知者方法，通知方法，必须有一个属性，用于保存通知者，通常是个数组类型。添加和删除方法直接对数组进行添加和删除操作。而通知方法里会使用一个遍历，让所有保存在数组中的被通知者调用某个方法，也就是通知它们做出反应。被通知者类必须实现一个方法，就是用于被通知时做出的反应的方法，这个方法事实上是要被通知者类的通知方法调用的。目前为止，还只是通知者单方面地对被通知者进行通信。如何让被通知者得到通知者新的状态呢？通过对被通知者类的构造函数传入通知者对象，从而让被通知者可以得到通知者对象的状态。因为对于对象类型来说，用的是传址方式，所以，在被通知者的反应方法中，如果通知者状态发生了变化，被通知者是可以随时得到新的状态的。

　也就是说，通知者通过添加和删除被通知者，将通知者列表保存在自己的属性中，在通知方法是遍历实现通知每个被通知者；而被通知者通过在构造函数中被传到通知者，从来和通知者建立通信，得到通知者变化的新状态。通知者和被通知者双向耦合着。