行動パターン

イテレーター

イテレータは動作設計パターンです。各集約オブジェクトの説明を使用せずに集約オブジェクトの要素に順次アクセスできるようにするオブジェクトを表します。

たとえば、ツリー、リンク リスト、ハッシュ テーブル、配列などの要素は、Iterator オブジェクトを使用して走査 (および変更) できます。

要素の反復は、コレクション自体ではなく、イテレーター オブジェクトによって実行されます。これにより、コレクションのインターフェイスと実装が簡素化され、懸念事項のより論理的な分離が促進されます。

完全に実装されたイテレータの特徴は、イテレータを使用するコードが、反復された集合体の型について何も知らない可能性があることです。

このアプローチは非常に頻繁に使用されます。たとえば、SQL クエリをデータベースに送信すると、応答としてイテレータ (SQL 用語では通常カーソルと呼ばれます) が返されます。そして、結果として得られるイテレータを利用して、SQL 応答から行を 1 つずつ取得できます。

指図

コマンドは、アクションを表すオブジェクト指向プログラミングで使用される動作設計パターンです。コマンド オブジェクトには、アクション自体とそのパラメーターが含まれます。

メソッドを呼び出すには、通常、次のものが必要です。

• オブジェクト参照
• メソッド名 (メソッド参照)
• メソッドのパラメータ値
• 使用されるオブジェクトを含むコンテキストへの参照

このすべてのデータは 1 つのオブジェクト、コマンド ( command )にパックする必要があります。

しかし、それだけではありません。結局のところ、誰かがコマンドを実行する必要があります。したがって、このパターンにはさらに 4 つのエンティティ (コマンド ( command )、コマンド受信者 (レシーバー)、コマンド呼び出し元 ( invoker )、およびクライアント ( client ) が含まれます。

オブジェクト指図受信側について認識しており、受信側メソッドを呼び出します。受信機のパラメータ値はコマンドに保存されます。呼び出し元 (実行者) はコマンドの実行方法を知っており、実行されたコマンドを追跡している可能性があります。呼び出し元 (実行者) は特定のコマンドについては何も知りません。インターフェースについてのみ知っています。

両方のオブジェクト (呼び出し元オブジェクトといくつかのコマンド オブジェクト) はクライアント オブジェクトに属します。クライアントは、どのコマンドをいつ実行するかを決定します。コマンドを実行するには、コマンド オブジェクトを呼び出し元 (呼び出し元) に渡します。

コマンド オブジェクトを使用すると、クラス メソッドやメソッド パラメーターを知らなくても、いつでも委任したりメソッド呼び出しを行う必要がある共有コンポーネントを簡単に構築できます。

呼び出し元オブジェクト (呼び出し側) を使用すると、クライアントがこのアカウンティング モデルについて知らなくても、実行されたコマンドの記録を保持できます (このようなアカウンティングは、コマンドの取り消しややり直しの実装などに役立ちます)。

たとえば、さまざまなタスクをスケジュールに従って実行できるプログラムを作成しているとします。一方では、プログラムはタスクを追跡し、その起動を管理します。他方では、プログラムは複数のエグゼキューターを持ち、それぞれが独自のタイプのコマンドを実行できます。たとえば、SMS の送信、手紙の送信、Telegram へのメッセージの送信などです。

観察者

オブザーバーは動作設計パターンです。このクラスのオブジェクトが他のオブジェクトの状態の変化に関する通知を受信し、それを監視できるようにするクラス メカニズムを実装します。

他のクラスがサブスクライブするクラスはサブジェクトと呼ばれ、サブスクライブするクラスはオブザーバーと呼ばれます。

Observer パターンを実装する場合、次のクラスが一般的に使用されます。

• Observable - オブザーバーを追加、削除、通知するためのメソッドを定義するインターフェイス。
• オブザーバー- オブザーバーが通知を受信するインターフェイス。
• ConcreteObservableは、 Observableインターフェイスを実装する具象クラスです。
• ConcreteObserver は、 Observerインターフェイスを実装する具象クラスです。

Observer パターンは、システムが次の場合に使用されます。

• メッセージを送信するオブジェクトが少なくとも 1 つあります。
• メッセージの受信者は少なくとも 1 人存在し、その数と構成はアプリケーションの実行中に変更される可能性があります。
• 相互作用するクラスの強い結合を回避します。

このパターンは、メッセージの送信者が、受信者が提供された情報を使って何をするかに興味がない状況でよく使用されます。

ビジター

ビジターは、他のクラスのオブジェクトに対して実行される操作を記述する動作設計パターンです。訪問者が変わっても、サービスクラスを変更する必要はありません。

このテンプレートは、ダウンキャストの二重ディスパッチに頼ることなく、失われた型情報を回復するための古典的な手法を示しています。

多数のオブジェクトに対して切断された操作を実行する必要がありますが、それらのコードを汚染しないようにする必要があります。また、目的の操作を実行する前に、各ノードの型をクエリしてポインタを正しい型にキャストする方法も希望もありません。

このテンプレートは、次の場合に使用する必要があります。

• さまざまなインターフェイスを持つさまざまなクラスのさまざまなオブジェクトがありますが、特定のクラスに依存する操作をそれらに対して実行する必要があります。
• 構造上、さまざまな操作を行う必要があり、構造が複雑になる。
• 構造に対する新しい操作がしばしば追加されます。

仲介者

Mediator は、疎結合を維持し、オブジェクトが相互に明示的に参照する必要性を回避しながら、複数のオブジェクトが対話できるようにする動作設計パターンです。

Mediator パターンを使用すると、疎結合を形成し、オブジェクトが相互に明示的に参照する必要性を排除しながら、多くのオブジェクトの相互作用を保証できます。

メディエーターは、オブジェクトと情報を交換するためのインターフェースを定義します。同僚,特定の仲介者がオブジェクトの動作を調整します。同僚。

各同僚クラスはそのオブジェクトについて知っています調停者、すべての同僚は仲介者とのみ情報を交換し、仲介者がいない場合は直接情報を交換する必要があります。

同僚Reseller/span> にリクエストを送信し、そこからリクエストを受信します。メディエーターは、各リクエストを 1 つ以上のサーバーに転送することで協調動作を実装します。同僚。