個々のオブジェクトを完了するために一緒に協力する方法について説明し、実行時に複雑なフロー制御記述のための行動モデルは、アルゴリズムとオブジェクト間の責任の割り当てに関連する複数のクラスまたはオブジェクト間のみタスクを完了することができません。
クラスとオブジェクトの挙動の行動パターンに行動パターンは、前者はオブジェクト間の重合または分配挙動の組み合わせを使用してクラス間の挙動を、ディスパッチする継承メカニズムを使用します。組合せ又は結合関係よりも低い凝集関係継承関係を満たすために「合成多重原理」を、オブジェクトの動作パターンは、クラスの振る舞いより大きな柔軟性を有します。
行動パターンGoFのデザインパターンは、次の11のモードが含まれているクラスの中で最大です。
- テンプレートの方法（テンプレート法）モード：アルゴリズムは動作のスケルトンを定義し、アルゴリズムのステップのいくつかは、サブクラスを遅らせる、このアルゴリズム構造の場合には、アルゴリズムの特定の段階で変更することはできませんサブクラスが再定義。
- 戦略（ストラテジー）モード：彼らはお互いを置き換えることができるように、一緒にアルゴリズムのセット、および各アルゴリズムのパッケージを定義し、アルゴリズムの変更は、アルゴリズムを使用している顧客には影響を与えません。
- コマンド（コマンド）モード：オブジェクトに対する要求をカプセル化するので、リクエストの実行と責任を分離要求します。
- デューティ鎖（責任の連鎖）モード：対象からチェーン内の次のオブジェクトに送信された要求、要求が受け付けられるまでアップ。このようにしてオブジェクト間の結合を除去します。
- 状態（状態）モード：ときに内部状態が変化するオブジェクトがその容量を変更することを可能にします。
- 観察者（観察）モード：オブジェクトが変更された場合、複数のオブジェクト間の多くの関係が、変化が他のオブジェクトの動作に影響する他の複数のオブジェクトに通知されます。
- メディエーター（メディエーター）はモード：仲介オブジェクトを定義するように、互いの間に元のターゲットを知らなくても、システム内のオブジェクトとの間の結合を低減する、元のターゲットとの間の相互作用を簡素化することです。
- 反復子（イテレータ）モード：オブジェクトの内部表現を公開せず、重合中のデータオブジェクトの一連の重合をシーケンシャルアクセス方法を提供します。
- 訪問者（ユーザー）モード：各要素のセットにアクセスするためのさまざまな方法を提供する前提を変更することなく、要素の集合、すなわち各要素は、訪問者のアクセス・オブジェクトを複数有しています。
- 覚書（メメント）モード：パッケージを破壊することなく、取得し、後でそれを回復するために、オブジェクトの内部状態を記憶します。
- インタプリタ（インタプリタ）モード：文法、言語及び言語文の解釈、すなわち、インタプリタを提供する方法を定義します。
テンプレートメソッドパターンに加えて、行動パターンの以上11種類のモードを説明するすべてのI意志詳しくその特性、構造およびアプリケーションの下、他のオブジェクトの行動パターンに属するクラス行動パターンです。
Template Methodパターン
オブジェクト指向プログラミングの過程では、プログラマはしばしばこのような状況が発生した：システムのアルゴリズムを設計するために必要な重要なステップを知っており、これらのステップの実行順序、まだ未知の特定のステップの特定の実装を決定するために、または特定の環境に関連した特定のステップを達成。
さ、数、キューイング、特定のビジネスを扱う、銀行のスタッフと番号を取る他の格付けを、取るラインアップし、各顧客にサービスを提供するために、銀行の職員について採点：たとえば、次の4つのプロセスを通過します取引をするために銀行に行きます同じ親クラスで達成することができるが、彼らは特定のビジネスを扱う異なり、それはなどの預金、引き出しや転送であってもよい、サブクラス実装まで遅延することができます。
モデルの定義と特性
メソッド定義されたテンプレート（テンプレート法）モードは以下の通りである：スケルトンアルゴリズムの動作の定義をサブクラスアルゴリズムアルゴリズムの再定義の構造のいくつかのこのような場合は変更することができない、サブクラスを遅延するためのアルゴリズムのいくつかのステップ具体的な手順。これは、行動パターンのクラスです。
メインモードの利点としては、以下の通りです。
- それは不変部分、可変の延長部分をカプセル化します。それは達成カプセル化された親部分に同じアルゴリズム、およびサブクラスに継承実装されたアルゴリズムの可変部分を信じて、サブクラスは継続的拡張を容易です。
- これは、コードの再利用を容易にする、親クラスのコードの公開部分を抽出します。
- この方法は、サブクラスの一部によって実現される、サブクラスが開閉の原理に沿って、対応する方法を拡張することによって増加させることができます。
メインモード欠点としては、以下の通りです。
- 私たちは、クラス、はるかに大きいシステム、設計、より抽象的な数の増加につながることができ、それぞれ異なる実装のためのサブクラスを定義する必要があります。
- 抽象親クラスは、サブクラスによって実装され、サブクラスの実行結果は、逆方向制御構造をもたらす親クラスの結果に影響を与え、それはコードを読み取ることの難しさを増加させます。
アーキテクチャと実装モデル
Template Methodパターンは、抽象と具象サブクラス間の連携に留意する必要があります。それは、「私はあなたを呼ぶことにしましょう、私を呼び出すことはありません」多型と仮想関数リバース制御技術を使用しています。今、彼らの基本的な構造を導入。
1.構造モデル
Template Methodパターンは、次の主要な役割で構成されています。
（1）抽象（抽象クラス）：スケルトンの責任と輪郭アルゴリズムを与えます。これは、テンプレートメソッドと基本的なメソッドの数で構成されています。次のようにこれらのメソッドが定義されています。
1.テンプレートメソッド：アルゴリズムは、本質的に特定の順序でメソッドを呼び出す含む、スケルトンを定義します。
2.基本的な方法：アルゴリズムのステップは、以下のタイプを含みます。
- 抽象メソッド：抽象クラスが肯定、具象サブクラスで実装されています。
- 具体的な方法：抽象クラスで達成されている、それが継承さをオーバーライドしたり、特定のサブクラス化することができます。
- フック方法：抽象クラスで達成されている、両方の方法に使用されるブランクを含む、ロジックと書き換えサブクラスを決定する方法を必要とします。
（2）特定のサブクラス（具象クラスは、）：トップレベルのロジックの積分ステップである抽象クラスで定義された抽象メソッドとフックメソッドを実装します。
図1に示すテンプレートメソッドパターン構成図。
テンプレートメソッドの図の構成図
シーンモードの応用
Template Methodパターンは、通常のシーンで使用されています。
- アルゴリズムの全体的な手順は、固定されているが、個々の部品の際に変数は、この方法は、テンプレートパターンは、部分は、サブクラスが実装によって抽象化される傾向にあるときに使用することができます。
- サブクラス共通の挙動が複数存在する場合、それを抽出し、コードの重複を避けるために、共通の親クラスに濃縮することができます。まず、違いを識別するためのコード、および分離を既存のは、新しい操作は異なっています。最後に、これらの異なるコードの動作方法を置き換えるために、新しいテンプレートの呼び出し。
- 拡張サブクラスを制御する必要性は、テンプレートが呼び出されたときにのみ、これらの点で、拡張を可能にするようにだけ、特定の時点での動作をフック。
拡張モード
テンプレート方式モードにおいて、実質的に前記抽象メソッド、フック方法、および特定の方法、「フックメソッド」の適切な使用を親クラスのそのようなサブクラスの動作を制御することができます。次の例のように、抽象親クラスの業績を変更するために、サブクラス特定フック方法HookMethod1（）とHookMethod2（）でオーバーライドすることができ、構造は、図2に示します。
のテンプレートメソッドフック方法を含む図2の構成図
戦略モード
実生活では、多くの場合、選択する特定の目標を達成するための様々な戦略の存在下で遭遇した、例えば、旅行者は飛行機、電車、自転車で旅行や自分の自家用車を開始することができ、スーパーマーケットでは、商品の配送をプロモーション割引の使用を排除すること統合や他の方法を送信します。
ソフトウェア開発では、多くの場合、そのようなデータが戦略バブルをソートすると、似たような状況は、特定の機能を実現する複数のアルゴリズムや戦略がある場合、我々は環境条件やアルゴリズムや戦略に応じて、異なるオプションの機能を実行することができ遭遇ソート、選択ソート、挿入ソート、バイナリ・ソート。
あなたは（つまり、ハードコードされている）を達成するために、複数の条件分岐文を使用している場合は、条件文だけではなく、保守が容易で、開閉の原則に反して非常に複雑になり、追加、ソースコードを変更するためのアルゴリズムを削除するか、または交換してください。パターンは、問題を解決するには良い戦略であることができます。
戦略パターンの定義と特性
定義された戦略（ストラテジー）モード：このモードでは、アルゴリズムのセットを定義し、それらが相互に交換することができるように、各アルゴリズムをカプセル化し、アルゴリズムの変更は、アルゴリズムを使用している顧客には影響を与えません。ストラテジーパターンは、それが責任のアルゴリズム、アルゴリズムによってカプセル化アルゴリズムの使用が分離され、これらのアルゴリズムを管理するためのさまざまなオブジェクトに割り当てられた、オブジェクトの動作パターンに属します。
主な戦略モードの利点としては以下の通りです。
- 複数の条件文は、維持し、複数の条件文の使用を避けるために、戦略パターンを使用することは容易ではありません。
- Strategyパターンは、再利用可能なアルゴリズムの家族の範囲を提供していますコードの重複を避けるために、アルゴリズムを適切に使用するには、親クラスに転送する共通コードの家族を継承することができます。
- 戦略モードは同じ動作の異なる実装を提供することができ、顧客は、異なる時間または異なる容量の要件を選択することができます。
- 戦略モードでは、開閉の原則のための完全なサポートを提供し、元のコードを変更することなく、新しいアルゴリズムを追加柔軟にすることができます。
- 策略模式把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现了二者的分离。
其主要缺点如下。
- 客户端必须理解所有策略算法的区别，以便适时选择恰当的算法类。
- 策略模式造成很多的策略类。
策略模式的结构与实现
策略模式是准备一组算法，并将这组算法封装到一系列的策略类里面，作为一个抽象策略类的子类。策略模式的重心不是如何实现算法，而是如何组织这些算法，从而让程序结构更加灵活，具有更好的维护性和扩展性，现在我们来分析其基本结构和实现方法。
1. 模式的结构
策略模式的主要角色如下。
- 抽象策略（Strategy）类：定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，环境角色使用这个接口调用不同的算法，一般使用接口或抽象类实现。
- 具体策略（Concrete Strategy）类：实现了抽象策略定义的接口，提供具体的算法实现。
- 环境（Context）类：持有一个策略类的引用，最终给客户端调用。
其结构图如图 1 所示。
图1 策略模式的结构图
策略模式的应用场景
策略模式在很多地方用到，如JavaSE 中的容器布局管理就是一个典型的实例，Java SE 中的每个容器都存在多种布局供用户选择。在程序设计中，通常在以下几种情况中使用策略模式较多。
- 一个系统需要动态地在几种算法中选择一种时，可将每个算法封装到策略类中。
- 一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现，可将每个条件分支移入它们各自的策略类中以代替这些条件语句。
- 系统中各算法彼此完全独立，且要求对客户隐藏具体算法的实现细节时。
- 系统要求使用算法的客户不应该知道其操作的数据时，可使用策略模式来隐藏与算法相关的数据结构。
- 多个类只区别在表现行为不同，可以使用策略模式，在运行时动态选择具体要执行的行为。
策略模式的扩展
在一个使用策略模式的系统中，当存在的策略很多时，客户端管理所有策略算法将变得很复杂，如果在环境类中使用策略工厂模式来管理这些策略类将大大减少客户端的工作复杂度，其结构图如图2所示。
图2策略工厂模式的结构图
命令模式
在软件开发系统中，常常出现“方法的请求者”与“方法的实现者”之间存在紧密的耦合关系。这不利于软件功能的扩展与维护。例如，想对行为进行“撤销、重做、记录”等处理都很不方便，因此“如何将方法的请求者与方法的实现者解耦？”变得很重要，命令模式能很好地解决这个问题。
在现实生活中，这样的例子也很多，例如，电视机遥控器（命令发送者）通过按钮（具体命令）来遥控电视机（命令接收者），还有计算机键盘上的“功能键”等。
命令模式的定义与特点
命令（Command）模式的定义如下：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通，这样方便将命令对象进行储存、传递、调用、增加与管理。
命令模式的主要优点如下。
- 降低系统的耦合度。命令模式能将调用操作的对象与实现该操作的对象解耦。
- 增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类，它满足“开闭原则”，对扩展比较灵活。
- 可以实现宏命令。命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。
- 方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合，实现命令的撤销与恢复。
其缺点是：可能产生大量具体命令类。因为计对每一个具体操作都需要设计一个具体命令类，这将增加系统的复杂性。
命令模式的结构与实现
可以将系统中的相关操作抽象成命令，使调用者与实现者相关分离，其结构如下。
1. 模式的结构
命令模式包含以下主要角色。
- 抽象命令类（Command）角色：声明执行命令的接口，拥有执行命令的抽象方法 execute()。
- 具体命令角色（Concrete Command）角色：是抽象命令类的具体实现类，它拥有接收者对象，并通过调用接收者的功能来完成命令要执行的操作。
- 实现者/接收者（Receiver）角色：执行命令功能的相关操作，是具体命令对象业务的真正实现者。
- 调用者/请求者（Invoker）角色：是请求的发送者，它通常拥有很多的命令对象，并通过访问命令对象来执行相关请求，它不直接访问接收者。
其结构图如图 1 所示。
图1 命令模式的结构图
命令模式的应用场景
命令模式通常适用于以下场景。
- 当系统需要将请求调用者与请求接收者解耦时，命令模式使得调用者和接收者不直接交互。
- 当系统需要随机请求命令或经常增加或删除命令时，命令模式比较方便实现这些功能。
- 当系统需要执行一组操作时，命令模式可以定义宏命令来实现该功能。
- 当系统需要支持命令的撤销（Undo）操作和恢复（Redo）操作时，可以将命令对象存储起来，采用备忘录模式来实现。
命令模式的扩展
在软件开发中，有时将命令模式与前面学的组合模式联合使用，这就构成了宏命令模式，也叫组合命令模式。宏命令包含了一组命令，它充当了具体命令与调用者的双重角色，执行它时将递归调用它所包含的所有命令，其具体结构图如图2 所示。
图2组合命令模式的结构图
责任链模式
在现实生活中，常常会出现这样的事例：一个请求有多个对象可以处理，但每个对象的处理条件或权限不同。例如，公司员工请假，可批假的领导有部门负责人、副总经理、总经理等，但每个领导能批准的天数不同，员工必须根据自己要请假的天数去找不同的领导签名，也就是说员工必须记住每个领导的姓名、电话和地址等信息，这增加了难度。
模式的定义与特点
责任链（Chain of Responsibility）模式的定义：为了避免请求发送者与多个请求处理者耦合在一起，将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。
注意：责任链模式也叫职责链模式。
在责任链模式中，客户只需要将请求发送到责任链上即可，无须关心请求的处理细节和请求的传递过程，所以责任链将请求的发送者和请求的处理者解耦了。
责任链模式是一种对象行为型模式，其主要优点如下。
- 降低了对象之间的耦合度。该模式使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构，发送者和接收者也无须拥有对方的明确信息。
- 增强了系统的可扩展性。可以根据需要增加新的请求处理类，满足开闭原则。
- 增强了给对象指派职责的灵活性。当工作流程发生变化，可以动态地改变链内的成员或者调动它们的次序，也可动态地新增或者删除责任。
- 责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用，不需保持其他所有处理者的引用，这避免了使用众多的 if 或者 if···else 语句。
- 责任分担。每个类只需要处理自己该处理的工作，不该处理的传递给下一个对象完成，明确各类的责任范围，符合类的单一职责原则。
其主要缺点如下。
- 不能保证每个请求一定被处理。由于一个请求没有明确的接收者，所以不能保证它一定会被处理，该请求可能一直传到链的末端都得不到处理。
- 对比较长的职责链，请求的处理可能涉及多个处理对象，系统性能将受到一定影响。
- 职责链建立的合理性要靠客户端来保证，增加了客户端的复杂性，可能会由于职责链的错误设置而导致系统出错，如可能会造成循环调用。
模式的结构与实现
通常情况下，可以通过数据链表来实现职责链模式的数据结构。
1. 模式的结构
职责链模式主要包含以下角色。
- 抽象处理者（Handler）角色：定义一个处理请求的接口，包含抽象处理方法和一个后继连接。
- 具体处理者（Concrete Handler）角色：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以处理请求则处理，否则将该请求转给它的后继者。
- 客户类（Client）角色：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。
其结构图如图 1 所示。客户端可按图 2 所示设置责任链。
图1 责任链模式的结构图
图2 责任链
模式的应用场景
前边已经讲述了关于责任链模式的结构与特点，下面介绍其应用场景，责任链模式通常在以下几种情况使用。
- 有多个对象可以处理一个请求，哪个对象处理该请求由运行时刻自动确定。
- 可动态指定一组对象处理请求，或添加新的处理者。
- 在不明确指定请求处理者的情况下，向多个处理者中的一个提交请求。
模式的扩展
职责链模式存在以下两种情况。
- 纯的职责链模式：一个请求必须被某一个处理者对象所接收，且一个具体处理者对某个请求的处理只能采用以下两种行为之一：自己处理（承担责任）；把责任推给下家处理。
- 不纯的职责链模式：允许出现某一个具体处理者对象在承担了请求的一部分责任后又将剩余的责任传给下家的情况，且一个请求可以最终不被任何接收端对象所接收。
状态模式
在软件开发过程中，应用程序中的有些对象可能会根据不同的情况做出不同的行为，我们把这种对象称为有状态的对象，而把影响对象行为的一个或多个动态变化的属性称为状态。当有状态的对象与外部事件产生互动时，其内部状态会发生改变，从而使得其行为也随之发生改变。如人的情绪有高兴的时候和伤心的时候，不同的情绪有不同的行为，当然外界也会影响其情绪变化。
对这种有状态的对象编程，传统的解决方案是：将这些所有可能发生的情况全都考虑到，然后使用 if-else 语句来做状态判断，再进行不同情况的处理。但当对象的状态很多时，程序会变得很复杂。而且增加新的状态要添加新的 if-else 语句，这违背了“开闭原则”，不利于程序的扩展。
以上问题如果采用“状态模式”就能很好地得到解决。状态模式的解决思想是：当控制一个对象状态转换的条件表达式过于复杂时，把相关“判断逻辑”提取出来，放到一系列的状态类当中，这样可以把原来复杂的逻辑判断简单化。
状态模式的定义与特点
状态（State）模式的定义：对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。
状态模式是一种对象行为型模式，其主要优点如下。
- 状态模式将与特定状态相关的行为局部化到一个状态中，并且将不同状态的行为分割开来，满足“单一职责原则”。
- 减少对象间的相互依赖。将不同的状态引入独立的对象中会使得状态转换变得更加明确，且减少对象间的相互依赖。
- 有利于程序的扩展。通过定义新的子类很容易地增加新的状态和转换。
状态模式的主要缺点如下。
- 状态模式的使用必然会增加系统的类与对象的个数。
- 状态模式的结构与实现都较为复杂，如果使用不当会导致程序结构和代码的混乱。
状态模式的结构与实现
異なる状態オブジェクトの環境のパッケージで動作を変更するには、オブジェクトモデルの状態は、その意図は、彼らの行動が変更されたときにオブジェクトがその内部状態を変更することです。今、私たちは基本的な構造と実装を分析する必要があります。
1.構造モデル
状態モデルは、次の主要な役割で構成されています。
- 環境（コンテキスト）の役割：またコンテキストと呼ばれる、処理するオブジェクトの現在の動作状態に関連する現在の状況と委託状態を維持し、クライアントにとって関心のインタフェースを定義します。
- 抽象状態（ステート）の役割：行動に対応する特定のパッケージ環境状態オブジェクトのインタフェースを定義します。
- 特定の状態（コンクリート州）の役割：行動に対応する抽象状態。
図1に示す構造。
図の状態パターン構成図。1
アプリケーションシナリオの状態モード
一般的に使用される状態モデルは、次のような場合に考慮することができます。
- オブジェクトの振る舞いは、その状態に依存し、それは実行時に状態に応じてその動作を変更しなければならないときは、使用状態モードを考慮することができます。
- 含まれる大分岐構造を操作し、オブジェクトの分岐の状態を判断した場合。
拡張ステータスモード
いくつかの場合において、複数のオブジェクトは、次に、環境状態のセット、フライ級、番組共有のためのオブジェクトのセット状態において特にそれらを導入する必要性を共有する必要があるかもしれない、構造が図2に示されています。
図2は、共有状態モードの構成図です。
分析：共有状態モードの違いは、あなたがそれからの状態のいくつかの並べ替えを必要とするとき、あなたが得ることができる環境カテゴリに関連する状態を保持するためのHashMapの追加です。