行動
アルゴリズムとオブジェクト間の責任の配分に関連した行動パターン
行動パターンだけではなく、オブジェクトまたはクラスのモデルを記述もの間の通信の彼らのモードを説明し
、これらのパターンの制御フローからあなたの注意を追跡するために、実行困難で複雑な制御フローを特徴づけます物体までの間のリンクに転送
責任デューティチェーンのチェーン
意图
オブジェクトの複数の送信側と受信側の要求との間の結合を回避するために要求を処理する機会
チェーンに接続されたオブジェクトを、チェーンに沿って要求を渡します直到有一个对象处理他
适用性
- リクエストを実行する要求を処理する場合の処理の複数のオブジェクトは自動的にどのオブジェクトを決定することができます
- あなたが明示的に指定した受信者なしで複数のオブジェクトに要求を提出したいですか
- リクエストを処理して、動的に割り当てる必要があるオブジェクトの集合であってもよいです
结构图
效果
- カップリングを削減
- オブジェクトに責任を割り当てる柔軟性を強化
不保证被请求被接受处理
效果
- クライアントが要求を送信するとオブジェクトハンドルそれConcreteHandleまで、チェーンに沿って要求を渡します
实现
- 後継チェーンを達成
- 接続の後継者
- それは要求することを示し
3.1リクエストがゴミであるハードコードされたオペレーションの呼び出しで
パラメータ要求コードに処理関数関数用いて3.2
別個Requestオブジェクトとして3.3リクエストを包装することができる
、これを識別するための要求が要求にアクセス制御を定義することができるものです要求識別子に戻る(アクセサ)
相关模式
- 多くの場合、親メンバーの一員で、この場合に使用することができます彼の後継者としてCompositeパターン
コマンドコマンド
意图
したがって、このようなログや支持体または元に戻すよう要求キューの要求の異なるパラメータを使用して、あなたのクライアントを作成するオブジェクトの要求をカプセル化
适用性
- そのようなパラメータは、手続き型言語機構コールバック関数を用いて表すことができるパラメトリックオブジェクトに実行される抽象アクション
コマンドパターンは、オブジェクト指向の製品コールバック機構であります - 異なる時間におよび実行するための要求を指定するように配置されている
Commandオブジェクトを初期の要求に依存しないライフサイクルを持つことができます
に関係なく、受信者のアドレスの要求処理別のプロセスに転送することができ、そのような要求のアドレス空間として - サポート前の状態では操作をキャンセル保存しunexecuteを実行することができます
- サポート変更ログ
- 等
结构图
协作
-
特定のオブジェクトを作成するには、クライアントと
设定他的接收者
-
Commandオブジェクト・ストレージ・実行者
-
コマンドの実行を呼び出すことによって要求を提出する実行者
实现
-
以下のように...
-
C ++のテンプレートを使用することは避けてくださいは、すべてのアクションと受信者のコマンド・サブクラスを作成し、
相关模式
- 複合モードは、マクロコマンドを実装するために使用することができます
- メメント・モードは、supportコマンドの取り消します状態を維持するために使用することができます
- 以下のように...
通訳通訳
意图
彼は文法表現定義された言語を考えると定義インタプリタインタプリタ言語で文章を解釈する表現を使用しています
动机
問題の特定の種類の周波数が十分に高い個々のインスタンスが発生した場合には、問題は言語の単純な文章として表現される価値があるかもしれ
インタプリタは、これらの文を解釈することによってこの問題を解決するためのインタプリタのメンバーとすることができるように
结构图
这图我看起来就觉得像是一个Composite的模式
相关模式
- コンポジット:抽象構文木は、マルチモードの一例です
- フライ級:それは、抽象構文木にTerminalExpressionを共有する方法を説明します
- イテレータ:通訳可能なANはイテレータは、構造を横断します
- ビジター:各ノードの挙動は、クラスの抽象構文木を維持するために使用することができます
イテレータイテレータ
意图
そこに内部オブジェクトの逐次重合個々の要素にアクセスする方法を提供するが、オブジェクト表現の露出を必要としません。
结构图
实现
- 多くは、自分の本を読んでカザフスタン
メディエータのメディエータ
意图
オブジェクトの相互作用ブローカーのセットをカプセル化し、仲介オブジェクトを使用し使各个对象不需要显示的互相引用
、それは独立して、それらの間の疎結合の相互作用を変更することができるように、
动机
オブジェクト指向、各オブジェクトは一連の動作中に封入される単一メディエーターを介して他のすべてのオブジェクトを知っている最悪の場合にはオブジェクト間の多くの接続につながる可能性があり、この分布は個々のオブジェクトに分配様々なアクターを奨励この問題を回避するには 这里看起来有些像Facade
结构图
协作
同事向一个中介者对象发送消息和接收请求 中介者对象在各个同事之间适当的转发请求以实现协作行为
效果
- 减少子类生成
- Colleague解耦
- 简化了对象协议
- 对对象之间的协作进行了抽象
- 使控制集中化
但这也是问题所在 但这也是问题所在 但这也是问题所在
中介者模式将交互的复杂性变为中介者的复杂性 中介者过于复杂时可能会抵消该模式带来的好处
实现
- 当一个感兴趣的事情发生时 Colleague必须与其Mediator进行通信
一般使用Observer模式 或者在变化时调用一个Mediator的一个特殊通知接口 比如OnxxxChanged等等
相关模式
- Facade与中介者模式的不同在于 Facade是对一个对象子系统进行抽象 从而提供更为方便的接口 协议是单向的即
Facade对这个子系统类提出请求 但反之则不行
Mediator提供了个Colleague对象不支持或者不能协作的行为而且协议是多向的 - Colleague可以使用Observer模式与Mediator通信
Memento 备忘录
意图
在不破坏封装的前提下 捕获一个对象的内部状态 并在该对象外保存在状态 这个就可以在以后恢复这个对象到之前的状态
适用性
- 保存一个对象在某个时刻的部分状态 可以在以后需要时进行恢复
- 如果用一个接口来让其他对象直接得到这些状态 将会保留对象的实现细节并破会对象的封装性
结构图
协作
Caretaker
- 负责保存备备忘录 不能对备忘录的内容进行操作或检查
Originator
- 原发器创建备忘录或者用备忘录恢复
Memento
- 存储原发器的内部状态
- 一个只有Caretaker看到的窄接口 他只能将备忘录传递给其他对象
- 一个只有原发器的宽接口 允许访问返回到先前状态的所有数据
管理器向原发器请求一个备忘录 保留一段时间 然后返回给原发器 交互图如下
效果
- 保持封装的边界
- 简化了原发器
使用备忘录的代价可能较高 可能需要拷贝大量数据
定义上说的宽窄接口
维护备忘录的潜在代价
实现
- 语言支持
存储增量式改变
相关模式
- Command可以用Memento来支持可撤销操作
- Iterator备忘录可以用于迭代
Observer 观察者
意图
定义对象间的一种一对多的依赖关系 当一个对象发生状态的改变时 所有依赖于他的对象都得到通知并且被自动更新
动机
将一个系统分割成一系列互相协作的类有一个常见的副作用 维护相关对象的一致性
Observer是一种订阅发布模式
结构图
效果和实现
- …这个就不在具体描述了 这里着重一点
封装复杂的更新语义 可以称这个对象为更改管理器
目的是减少观察者反映其目标状态变化的工作量重要的是
一个操作设计到几个相互依赖的目标进行改动 就必须在所有的目标都完成改动后才一次性通知
相关模式
- Mediator 通过封装复杂的更新语义 ChangeManager 充当目标和观察者之间的中介者
- Singleton ChangeManager可以使用单件模式
State 状态
意图
允许一个对象在其内部状态改变时改变它的行为 对象看起来似乎是修改了他的类
适用性
- 对象的行为取决于他的状态 并且必须在运行时刻根据状态改变他的行为
- 一个操作中有大量的分支条件语句依赖于该对象的状态
结构图
实现
- 谁定义状态转换 如果转换规则是固定的 那么可以在Context中实现 然而让State子类自身指定他们的后继状态已经合适进行转换 往往更加灵活
不过这样的话需要在Context中增加一个接口让State显示的设定Context的当前状态 这种方法还一个缺点 一个State至少拥有了另一个子类的信息 在子类的实现之间产生了依赖-------------------我貌似更喜欢在state中指定后继
- 创建和销毁state
第一种
需要时创建并随后销毁第二种
提前创建不销毁 - …等等
相关模式
4. Flyweight 解释了何时以及如何共享状态
5. 状态对象通常都是Singleton
Strategy 策略
意图
定义一系列的算法 把他们一个个封装起来 并且使他们可以互换 本模式可以使算法可以独立于他的客户变化
结构图
这结构图 看起来就是一个 看起来就是一个 看起来就是一个 用一个委托的组合方式代替继承
协作
- context将请求转发给strategy 并且客户通常创建一个ConcreteStrategy给Context
效果
- 相关算法系列
- 一个代替继承的方法 比如不这样的话 其中一种方法是继承
Context
- 消除了一些条件语句 比如不这样的话 可以通过一些
if
进行不用的操作 - 实现的选择有了多样选择性
问题1
客户必须了解strategy的去呗问题2
Strategy与Context的通信开销 因为简单的ConcreteStrategy可能永远不会用到客户端传递过来的参数信息问题3
增加了对象数目(Strategy)可以用Flyweight来稍微减轻这影响
实现
- 定义Strategy和Context接口
- 可以将Strategy当做模板参数
- Strategy可以使可选的 没有的话可以执行缺省默认行为
相关模式
4. Flyweight Strategy对象通常是很好的轻量级对象
Template Method 模版方法
意图
定义一个操作中算法的骨架 而将一些步骤延迟到子类中 Template Method 使得子类可以不改变一个算法的结构就可以重定义这个算法中的某些特定步骤
适用性
......其他不描述
- 可以控制子类扩展
只允许在某些特定的点进行扩展
结构图
效果
- 模板方法导致一种反向的控制结构 这种结构称为
好莱坞原则 即 "别找我们 我们找你"
这里指的是父类调用子类的操作 而不是相反 - 也可以拿来做钩子操作
......等等
相关模式
- Factory Method 常被模板方法调用
- Strategy 模版方法使用继承来改变算法的一部分 Strategy使用委托来改变整个算法
Visitor 访问者
意图
表示一个作用于某个对象结构中的各元素的操作 他可以使在不改变元素的类的前提下定义对这些元素的新操作
动机
使用Visitor模式 必须定义两个层次的类 一个
对应于接受操作的元素Node层次 另一个
对应于定义对元素的操作的访问者NodeVisitor层次
给访问者层次类增加一个新类就可以创建一个新的操作
结构图
参与者
- ObjectStructure 对象结构
就是在意图中说的那个包含很多对象的对象
协作
- 一个使用Visitor模式的客户必须创建一个ConcreteVisitor对象 然后遍历该对象结构并用该访问者访问每一个元素
- 当一个元素被访问时 它调用对应于它的Visitor操作
如果必要 可以将元素自身传递给Visitor以便访问元素状态
效果
- 易于增加新操作
- 访问者集中相关的操作而分离无关的操作
问题1
新增Element比较困难 需要在Visitor中添加相关操作 哈- 通过类层次进行访问
- 累积状态
问题2
破坏封装 访问者假定ConcreteElement功能足够强 足可以让访问者进行他的工作
那么该模式常常迫使你提供访问元素内部状态的公有操作而导致破坏封装
实现
双分派
自行查阅书籍- 訪問者は、次の3つの場所を移動するオブジェクト構造の各要素を訪問しなければならないオブジェクト構造を横断する責任がある責任を処理することができます
2.1オブジェクト構造
で2.2訪問者を
2.3または別のイテレータイテレータ
相关模式
- コンポジットの訪問者は、複合構造が動作オブジェクト・モデルを定義するために使用することができます
- 訪問者が説明するために使用することができます解釈