1.原型模式：使用原型实例指定创建对象的种类，并通过复制这个原型创建新的对象。
使用场景：
1.需要创建的对象应独立于其类型与创建方式。
2.要实例化的类实在运行时决定的。
3.不想要与产品层次相对应的工厂层次。
4.不同类的实例间的差异仅是状态的若干组合。因此复制相应数量的原型比手工实例化更加方便。
5.类不容易创建，不如每个组件可以把其他组件作为子节点的组合对象。复制已有的组合对象并对副本进行修改会更加容易。
2.工厂模式：定义创建对象的接口，让子类决定实例化哪一个类。工厂方法使得一个类的实例化延迟到其子类。
使用场景：
1.编译时无法准确预期要创建的对象的类。
2.类想要其子类决定在运行时创建什么。
3.类有若干辅助类为其子类，而你想将返回哪个子类这一信息局部化。
3.抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体的类。
抽象工厂对比工厂方法：
1.抽象工厂通过对象组合创建抽象产品；创建多系列产品；必须修改父类的接口才能支持新的产品。
2.工厂方法通过类继承创建抽象产品；创建一种产品；自泪花创建者并重载工厂方法以创建新产品。
4.建造者模式：将一个复杂对象的构建与它的表现分离，使得同样的构建过程可以创建不同的表现。
使用场景：
1.需要创建涉及各种总部件的复杂对象。创建对象的算法应该独立于部件的装配方式。常见例子是构建组合对象。
2.构建过程需要以不同的方式构建对象。
5.单例模式：保证一个类仅有一个实例，并提供一个访问他的全局访问点。
使用场景：
1.类智能有一个实例，而且必须从一个为人熟知的访问点对其进行访问，比如工厂方法。
2.这个唯一的实例只能通过自泪花进行扩展，而且扩展的对象不会破坏客户端代码。
6.适配器模式：将一个类的接口转换成客户希望的另外一个接口，适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
使用场景：
1.已有类的接口与需求不匹配。
2.想要一个可复用的类，该类能够同可能带有不兼容接口的其他类协作。
3.需要适配一个类的几个不同子类，可以让没一个子类去子类化一个类适配器又不现实。那个可以使用对象适配器（也叫委托）来适配其父类的接口。
7.桥接模式：将抽象部分与它的实现部分分离，使他们都可以独立的变化。
使用场景：
1.不想在抽象与其实现之间形成固定的绑定关系（这样就能在运行时切换实现）。
2.抽象及其实现都应可以通过子类化独立进行扩展。
3.对抽象的实现进行修改不应影响客户端代码。
4.如果每个实现需要额外的子类以细化抽象，则说明又还要把他们分成两个部分。
5.想在带有不同抽象接口的多个对象之间共享一个实现。
8.外观模式：为系统中的一组接口提供一个统一的接口，外观定义一个高层接口，让子系统更易于使用。
使用场景：
1.子系统正逐渐变得复杂。应用模式的过程中演化出许多类。可以使用外观这些子系统类提供一个较简单的接口。
2.可以使用外观对子系统进行分层。每个子系统级别有一个外观作为入口点。让它们通过其外观进行通信，可以简化它们的依赖关系。
9.中介者模式：用一个对象来封装一系列对象的交互方式。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
使用场景：
1.对象间的交互虽定义明确然而非常复杂，导致一组对象彼此相互依赖而且难以理解。
2.因为对象引用了许多其他对象并与其通讯，导致对象难以复用。
3.想要定制一个分布正在多个类中的逻辑或行为，又不想生成太多子类。
10.观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖他的对象都将得到通知并被自动更新。
使用场景：
1.有两个对象相互依赖。将它们封装在各自的对象中，就可以对它们单独进行改变和复用。
2.对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变。
3.一个对象必须通知其他对象，而它又不需要知道其他对象是什么。
11.组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。组合使得用户对单个对象和组合对象的使用具有一致性。
使用场景：
1.想要获得对象抽象的树形标识（部分-整体层次结构）。
2.想让客户端统一处理组合结构中的所有对象。
12.迭代器模式：提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。
使用场景：
1.需要访问组合对象的内容，而又不暴露其内部表示。
2.需要通过多种方式遍历组合对象。
3.需要提供一个统一的接口，用来遍历各种类型的组合对象。
13.访问者模式：表示一个作用于某对象结构中的各元素的操作。它让我们可以再不改变各元素的类的前提下定义作用于这些元素的新操作。
使用场景：
1.一个复杂的对象结构包含很多其他对象，他们有不同的接口（比如组合体），但是想对这些对象实施一些依赖于其具体类型的操作。
2.需要对一个组合结构中的对象进行很多不相关的操作，但是不想让这些操作“污染”这些对象的类。可以将相关的操作集中起来，定义在一个访问者类中，并在需要在访问者中定义的操作时使用它。
3.定义复杂结构的类很少作修改，但经常需要向其添加新的操作。
14.装饰模式：动态地给一个对象添加一些额外的职责。就扩展功能来说，装饰模式相比生成子类更为灵活。
使用场景：
1.想要在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
2.想要扩展一个类的行为，却做不到。类定义可能被隐藏，无法进行自泪花；或者，对类的每个行为的扩展，为支持每种功能组合，将产生大量的子类。
3.对类的职责的扩展是可选的。
15.责任链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间发生耦合。此模式将这些对象连城一条链，并沿着这条链传递请求，知道有一个对象处理它为止。
使用场景：
1.有多个对象可以处理请求，而处理程序只有在运行时才能确定。
2.向一组对象发出请求，而不想显示指定处理请求的特定处理程序。
16.模板方法模式：定义一个操作中算法的骨架，而将一些不周延迟到子类中。模板方法使子类可以重定义算法的某些特定步骤而不改变算法的结构。
使用场景：
1.需要一次性实现算法的不变部分，并将可变的行为留给子类来实现。
2.子类的共同行为应该被提取出来放到公共类中，以避免代码重复。现有代码的差别应该被分离为新的操作。然后用一个调用这些新操作的模板方法来替换这些不同的代码。
3.需要控制子类的扩展。
4.对具体类或者客户端类的具体操作。
5.对抽象类的具体操作。
6.抽象操作。
7.工厂方法。
8.钩子操作。
17.策略模式：定义一系列算法，把他们一个个封装起来，并且使他们可以相互替换。本模式使得算法可独立于使用它的客户而变化。
使用场景：
1.一个类在其操作中使用多个条件语句来定义许多行为。我们可以把相关的条件分支移到他们自己的策略类中。
2.需要算法的各种变体。
3.需要避免把复杂的、与算法相关的数据结构暴露给客户端。
18.命令模式：将请求封装为一个对象，从而可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。
使用场景：
1.想让应用程序支持撤销与恢复。享用对象参数化一个动作以执行操作，并用不同命令对象来代替回收函数。
2.想要在不同时刻对请求进行制定、排序和执行。
3.想记录修改日志，这样在系统故障时，这些修改可在后来重做一遍。
4.想让系统支持事务（transaction），事务封装了对数据的一系列修改。事务可以建模为命令对象。
19.享元模式：运用共享技术有小弟支持大量细力度的对象。
使用场景：
1.应用程序使用很多对象。
2.在内存中保存对象会影响内存性能。
3.对象的多数特有状态可以放到外部而轻量化。
4.移除了外在状态之后，可以用较少的共享对象替代原来的那组对象应用程序不依赖于对象标识，因为共享对象不同提供唯一的标识。
20.代理模式：为其他对象提供一种代理以控制对这个对象的访问。
使用场景：
1.需要一个远程代理，为位于不同地址空间或网络中的对象提供本地代表。
2.需要一个虚拟代理，来根据要求创建重型的对象。
3.需要一个保护代理，来根据不同访问权限控制对原对象的访问。
21.备忘录模式：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
使用场景：
1.需要保存一个对象（或某部分）在某一个时刻的状态，这样以后就可以恢复到先前的状态。
2.用于获取状态的接口会暴露实现的细节，需要将其隐藏起来。
22.解释器模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
使用场景：
1.重复发生的问题可以使用解释器模式。
2.一个简单语法需要解释的场景。
23.状态模式：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
使用场景：
1.一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。
2.代码中包含大量与对象状态有关的条件语句。
网友评论