州。 各州の州クラス

もちろん、これが階層を実装する唯一の方法ではありません。 ただし、Gang of Four State テンプレートを使用しない場合は機能しません。 代わりに、次のようにして、現在の状態とスーパーステートの明確な階層をモデル化できます。 スタックメインクラスの単一の状態ではなく、複数の状態。

現在の状態がスタックの最上位にあり、その下にそのスーパーステートがあり、その下にそのスーパーステートが配置されます。 これスーパーステートなど また、状態固有の動作を実装する必要がある場合は、スタックの最上位から開始して、状態が処理するまで下に向かって作業します。 (処理されない場合は、単純に無視します)。

マガジンメモリ付き自動機

ステート マシンには、ステート スタックを使用する別の一般的な拡張機能もあります。 ここでのみ、スタックはまったく異なる概念を表し、さまざまな問題を解決するために使用されます。

問題は、ステートマシンには概念がないことです 物語。 自分がどの状態にいるか知っていますか？ あなたは, しかし、自分がどのような状態にあるのかについての情報はありません。 だった。 したがって、以前の状態に戻す簡単な方法はありません。

簡単な例を次に示します。以前は、恐れを知らぬヒロインが全力で武装することを許可していました。 彼女が武器を発砲するとき、発砲アニメーションを再生し、弾丸を生成し、付随する視覚効果を行うための新しいステートが必要です。 これを行うには、新しい FiringState を作成し、ヒロインが発射ボタンを押すことで発砲できるすべての状態からそれに遷移します。

この動作は複数の状態間で複製されるため、ここで階層ステート マシンを使用してコードを再利用できます。

ここで難しいのは、どの状態に移行する必要があるのか​​を何らかの方法で理解する必要があることです。 後撮影。 ヒロインは静止しているとき、走っているとき、ジャンプしているとき、またはしゃがんでいるときにクリップ全体を発射できます。 撮影シーケンスが終了したら、撮影前の状態に戻る必要があります。

純粋な FSM に執着すると、自分がどのような状態にあったかをすぐに忘れてしまいます。 これを追跡するには、立っている射撃、走っている射撃、ジャンプしている射撃など、ほぼ同じ状態を多数定義する必要があります。 したがって、完了時に正しい状態に移行する遷移がハードコーディングされています。

本当に必要なのは、撮影前の状態を保存し、撮影後に再度思い出す能力です。 ここでもオートマトンの理論が役に立ちます。 対応するデータ構造はプッシュダウン オートマトンと呼ばれます。

有限オートマトンでは状態へのポインタが 1 つだけですが、ストア メモリを持つオートマトンでは状態へのポインタが存在します。 スタック。 FSM では、新しい状態への遷移により前の状態が置き換えられます。 マガジン メモリを備えたマシンでもこれを行うことができますが、さらに 2 つの操作が追加されます。

あなたはできる 場所 (押す) 新しい状態をスタックに追加します。 現在の状態は常にスタックの最上位にあるため、これは新しい状態に移行する操作です。 しかし同時に、古い状態はスタック上の現在の状態の直下に残り、跡形もなく消えることはありません。

あなたはできる 抽出する (ポップ) スタックの最上位状態。 状態は消え、その下にあったものが現在のものになります。

撮影に必要なのはこれだけです。 私たちが作成します 唯一のもの撮影状況。 別の状態で発射ボタンを押すと、 場所 (押す）スタック射撃状態。 撮影アニメーションが終了すると、 抽出する (ポップ) 状態に戻り、マガジン メモリを備えたマシンは自動的に前の状態に戻ります。

それらは実際にどれほど役立つのでしょうか?

このようにステート マシンが拡張されても、その機能は依然としてかなり制限されています。 今日の AI では、次のようなものを使用するのが一般的な傾向です。 ビヘイビアツリー(ビヘイビアツリー) と 計画システム(計画システム)。 AI の分野に特に興味がある場合は、この章全体が食欲をそそるはずです。 彼を満足させるには、他の本に目を向ける必要があります。

これは、有限状態マシン、マガジン メモリを備えたマシン、およびその他の同様のシステムがまったく役に立たないことを意味するものではありません。 いくつかの点では、これらは優れたモデリング ツールです。 ステート マシンは次の場合に役立ちます。

• 内部状態に応じて動作が変化するエンティティがあります。
• この条件は、比較的少数の特定のオプションに厳密に分割されます。
• エンティティは、一連の入力コマンドまたはイベントに継続的に応答します。

ゲームでは、ステート マシンは通常 AI のモデル化に使用されますが、ユーザー入力、メニュー ナビゲーション、テキスト解析、ネットワーク プロトコル、その他の非同期動作の実装にも使用できます。

状態は、オブジェクトの内部状態に応じて異なる機能を指定するオブジェクトの動作のパターンです。 ウェブサイト ウェブサイトのソース オリジナル

条件、タスク、目的

モチベーション

このパターンの主なアイデアは、抽象クラスを導入することです。 TCP状態さまざまな接続状態を表します。 このクラスは、さまざまなワーカーを記述するすべてのクラスに共通のインターフェイスを宣言します。 オリジナルソース.ru

状態。 これらのサブクラスでは TCP状態状態固有の動作が実装されます。 たとえば、授業では TCP確立済みそして TCP閉まっている状態固有の動作が実装されました 設立そして 閉まっているそれぞれ。 ウェブサイト ウェブサイトのオリジナルソース

オリジナル.ru

クラス TCP接続状態オブジェクト (サブクラスのインスタンス) を格納します。 TCP状態) 接続の現在の状態を表し、状態に依存するすべてのリクエストをこのオブジェクトに委任します。 TCP接続サブクラスの独自のインスタンスを使用します TCP状態非常に単純です: 単一のインターフェースのメソッドを呼び出す TCP状態、現在格納されている特定のサブクラスにのみ依存します TCP状態-a - 結果は異なります。つまり、 実際には、この接続状態にのみ固有の操作が実行されます。 オリジナル.ruソース

そして接続状態が変化するたびにTCP接続状態オブジェクトを変更します。 たとえば、確立された接続が閉じられると、 TCP接続クラスのインスタンスを置き換えます TCP確立済みコピー TCP閉まっている. サイトのオリジナルソースサイト

適用の兆候、State パターンの使用

1. オブジェクトの動作がその状態に依存し、実行時に変更する必要がある場合。 ソースoriginal.ru
2. オペレーションコードに多数の分岐からなる条件文が含まれており、分岐の選択が状態に依存する場合。 通常、この場合、状態は列挙された定数によって表されます。 多くの場合、同じ条件ステートメント構造が複数の操作で繰り返され、状態パターンでは各ブランチを別個のクラスに配置することが推奨されます。 これにより、オブジェクトの状態を、他のオブジェクトとは独立して変更できる独立したオブジェクトとして扱うことができます。 サイトソース 元のサイト

解決

ソース.ru

州パターンの参加者

1. コンテクスト(TCPConnection) - コンテキスト。
   クライアント用の単一インターフェイスを定義します。
   サブクラスのインスタンスを格納します コンクリートの状態、現在の状態を決定します。 コードラボ。
2. 州(TCPState) - 状態。
   特定のコンテキスト状態に関連付けられた動作をカプセル化するためのインターフェイスを定義します。 サイトソース サイトオリジナル
3. サブクラス コンクリートの状態(TCP確立、TCPListen、TCPClosed) - 特定の状態。
   各サブクラスは、何らかのコンテキスト状態に関連付けられた動作を実装します。 コンテクスト. サイトのオリジナルソースサイト

Stateパターンを使用するためのスキーム

コンテキストはそれ自体を引数としてオブジェクトに渡すことができます 州、リクエストが処理されます。 これにより、状態オブジェクト ( コンクリートの状態) 必要に応じてコンテキストにアクセスします。 コードラボ。

コンテクスト- これはクライアントのメイン インターフェイスです。 クライアントは状態オブジェクトを使用してコンテキストを構成できます 州（より正確に コンクリートの状態）。 コンテキストが設定されると、クライアントは状態オブジェクトと直接通信する必要がなくなります (共通インターフェイスを介してのみ通信する必要があります)。 州）。 ソース.ru

この場合、どちらか コンテクスト、またはサブクラス自体 コンクリートの状態どのような条件下で、どのような順序で状態の変化が起こるかを決定できます。 ウェブサイト ウェブサイトのソース オリジナル

State パターンの実装に関する質問

1. 状態間の遷移を決定するもの。
   状態パターンは、どの参加者が状態間の遷移の条件 (基準) を決定するかについては何も述べません。 基準が固定されている場合は、クラスに直接実装できます。 コンテクスト。 ただし、一般に、より柔軟で正しいアプローチは、クラス自体のサブクラスを許可することです。 州次の状態と移行の瞬間を決定します。 これを授業で行うには コンテクストオブジェクトから許可するインターフェースを追加する必要があります 州その状態を設定します。
   この分散型移行ロジックは変更と拡張が簡単です。新しいサブクラスを定義するだけで済みます。 州。 分散化の欠点は、各サブクラスが 州別の状態の少なくとも 1 つのサブクラス (実際に現在の状態を切り替えることができる) について「知っている」必要があり、これによりサブクラス間に実装の依存関係が生じます。 サイトソース サイトオリジナル

   ソースoriginal.ru

2. 表形式の代替案。
   ステート駆動型コードを構造化する別の方法もあります。 これが有限状態マシンの原理です。 テーブルを使用して入力を状態遷移にマッピングします。 これを利用すると、特定の入力データが到着したときにどの状態に移行する必要があるかを決定できます。 基本的に、条件付きコードをテーブル検索に置き換えています。
   このマシンの主な利点はその規則性です。移行基準を変更するには、コードではなくデータのみを変更するだけで十分です。 しかし、デメリットもあります。
   - テーブルの検索は、関数を呼び出すよりも効率が悪いことがよくあります。
   - 移行ロジックを統一した表形式で提示すると、基準が明確でなくなるため、理解が難しくなります。
   - 通常、状態間の遷移を伴うアクションを追加するのは困難です。 表形式の方法では状態と状態間の遷移が考慮されますが、状態の変化ごとに任意の計算を実行できるように補足する必要があります。
   テーブルベースのステート マシンとパターン ステートの主な違いは、次のように定式化できます。パターン ステートは状態依存の動作をモデル化し、テーブル メソッドはステート間の遷移の定義に焦点を当てます。 オリジナル.ru

   サイトのオリジナルソースサイト

3. 状態オブジェクトの作成と破棄。
   開発プロセスでは通常、次のいずれかを選択する必要があります。
   - 必要なときに状態オブジェクトを作成し、使用後すぐに破棄します。
   - 事前に永久に作成します。

   システムがどのような状態に陥るかが事前に不明であり、コンテキストによって状態が変化することは比較的まれである場合には、最初のオプションが推奨されます。 同時に、決して使用されないオブジェクトは作成しません。これは、多くの情報が状態オブジェクトに保存されている場合に重要です。 状態の変更が頻繁に発生し、それを表すオブジェクトを破棄したくない場合 (すぐに再び必要になる可能性があるため)、2 番目の方法を使用する必要があります。 オブジェクトの作成にかかる時間は最初の 1 回だけであり、破壊にはまったく時間がかかりません。 確かに、コンテキストにはシステムが理論的に陥り得るすべての状態への参照を格納する必要があるため、このアプローチは不便であることが判明する可能性があります。 ソースoriginal.ru

   source.ruオリジナル

4. 動的変更を使用します。
   実行時にオブジェクトのクラスを変更することで、オンデマンドの動作を変更することができますが、ほとんどのオブジェクト指向言語はこれをサポートしていません。 例外は、そのようなメカニズムを提供し、したがってパターン状態を直接サポートする Perl、JavaScript、およびその他のスクリプト エンジン ベースの言語です。 これにより、オブジェクトのクラス コードを変更することで動作を変えることができます。 ソース.ru

   .ruソースオリジナル

結果

1. 状態に依存する動作をローカライズします。
   そしてそれを状態に対応する部分に分割します。 状態パターンは、特定の状態に関連付けられたすべての動作を別のオブジェクトに入れます。 状態に依存するコードは完全にクラスのサブクラスの 1 つに含まれているため、 州そうすると、新しいサブクラスを生成するだけで、新しい状態と遷移を追加できます。
   代わりに、データ メンバーを使用して内部状態を定義し、その後オブジェクトの操作を定義することもできます。 コンテクストこのデータをチェックします。 ただし、この場合、同様の条件ステートメントまたは分岐ステートメントがクラス コード全体に散在することになります。 コンテクスト。 ただし、新しい状態を追加するにはいくつかの操作を変更する必要があり、メンテナンスが困難になります。 状態パターンはこの問題を解決しますが、異なる状態の動作が最終的に複数のサブクラスに分散されるため、別の問題も発生します。 州。 これによりクラス数が増加します。 もちろん、1 つのクラスの方がコンパクトですが、状態が多数ある場合は、そのような分散の方が効率的です。そうしないと、面倒な条件文を処理する必要があるからです。
   面倒な条件文があることは、長いプロシージャと同様に望ましくありません。 これらはモノリシックすぎるため、コードの変更と拡張が問題になります。 状態パターンは、状態に依存するコードを構造化するためのより良い方法を提供します。 状態遷移を記述するロジックはモノリシック ステートメントにラップされなくなりました もしまたは スイッチ、ただしサブクラス間で分散 州。 各遷移とアクションをクラスにカプセル化することで、状態は本格的なオブジェクトになります。 これにより、コードの構造が改善され、コードの目的がより明確になります。 オリジナル.ru
2. 状態間の遷移を明示的にします。
   オブジェクトが内部データのみの観点から現在の状態を定義する場合、状態間の遷移には明示的な表現がありません。 これらは、特定の変数への代入としてのみ表示されます。 異なる状態に個別のオブジェクトを導入すると、遷移がより明確になります。 さらに、オブジェクト 州コンテキストを保護できる コンテクストコンテキストの観点からの遷移はアトミックなアクションであるため、内部変数の不一致によるものです。 遷移するには、1 つの変数 (オブジェクト変数) の値のみを変更する必要があります。 州クラスで コンテクスト）、複数ではなく。 ソース.ru
3. 状態オブジェクトは共有できます。
   状態オブジェクト内の場合 州インスタンス変数はありません。つまり、それが表す状態は型自体によってのみエンコードされ、異なるコンテキストが同じオブジェクトを共有できます。 州。 このように国家が分離されると、それらの国家は本質的には内部国家を持たず、行動だけを持つ日和見主義者になります（日和見主義者のパターンを参照）。 サイトソース 元のサイト

例

まずはクラスを定義しましょう TCP接続、データ転送用のインターフェイスを提供し、状態変更リクエストを処理します: TCPConnection。 source.ruオリジナル

メンバー変数内 州クラス TCP接続クラスのインスタンスが保存される TCP状態。 このクラスは、クラスで定義された状態変更インターフェイスを複製します。 TCP接続. オリジナル.ruソース

サイトのオリジナルソースサイト

TCP接続状態に依存するすべてのリクエストを状態に格納されているインスタンスに委任します。 TCP状態。 授業中も TCP接続手術があります 状態の変更、これを使用して、別のオブジェクトへのポインタをこの変数に書き込むことができます TCP状態。 クラスコンストラクター TCP接続初期化します 州閉じた状態へのポインタ TCP閉まっている(以下で定義します)。 ソースoriginal.ru

source.ruオリジナル

あらゆる操作 TCP状態インスタンスを受け入れます TCP接続パラメータとして使用することで、オブジェクトを許可します TCP状態オブジェクトデータにアクセスする TCP接続接続状態を変更します。 .ru

クラスで TCP状態委任されたすべてのリクエストに対してデフォルトの動作を実装しました。 オブジェクトの状態を変更することもできます TCP接続手術を通して 状態の変更. TCP状態と同じパッケージ内にあります TCP接続なので、この操作 TCPState にもアクセスできます。 サイトのオリジナルソースサイト

オリジナル.ru

サブクラス内 TCP状態状態依存の動作が実装されました。 TCP 接続にはさまざまな状態が考えられます。 設立(インストール済み)、 聞いている（聞いている）、 閉まっている(closed) など、それぞれに独自のサブクラスがあります。 TCP状態。 簡単にするために、3 つのサブクラスのみを詳細に検討します。 TCP確立済み, TCPリッスンそして TCP閉まっている. ウェブサイト ウェブサイトのオリジナルソース

ルのソース

サブクラス内 TCP状態は、その状態で有効なリクエストに対して状態に依存した動作を実装します。 .ru

サイトのオリジナルソースサイト

状態固有のアクションを実行した後、これらの操作は ソースoriginal.ru

原因 状態の変更オブジェクトの状態を変更する TCP接続。 彼自身は TCP プロトコルに関する情報を持っていません。 サブクラスです TCP状態プロトコルによって指示された状態とアクションの間の遷移を定義します。 オリジナル.ru

ソースoriginal.ru

状態パターンの既知の応用例

エディターの動作の現在のツールへの依存を反映するには、状態パターンを使用できます。 オリジナルソース.ru

抽象クラスを定義できる 道具、そのサブクラスはツール固有の動作を実装します。 グラフィカルエディタは現在のオブジェクトへのリンクを保存します あまりにも私そして受信したリクエストを彼に委任します。 ツールを選択すると、エディターは別のオブジェクトを使用するため、動作が変わります。 .ru

この技術は、HotDraw および Unidraw グラフィック エディタのフレームワークで使用されます。 これにより、顧客は新しいタイプのツールを簡単に定義できるようになります。 で ホットドロークラス 描画コントローラリクエストを現在のオブジェクトに転送します 道具。 で ユニドロー対応するクラスが呼び出されます ビューアそして 道具。 以下のクラス図は、クラス インターフェイスの概略図を示しています。 道具

State パターンの目的

• State パターンを使用すると、オブジェクトの内部状態に応じて動作を変更できます。 オブジェクトのクラスが変更されたようです。
• State パターンは、ステート マシンのオブジェクト指向実装です。

解決すべき問題

オブジェクトの動作はその状態に依存し、プログラムの実行中に変更する必要があります。 このようなスキームは、多くの条件演算子を使用して実装できます。オブジェクトの現在の状態の分析に基づいて、特定のアクションが実行されます。 ただし、状態の数が多いと、条件ステートメントがコード全体に散在し、そのようなプログラムの保守が困難になります。

状態パターンの議論

State パターンは、この問題を次のように解決します。

• 外部へのインターフェースを定義する Context クラスを導入します。
• 抽象 State クラスを導入します。
• ステート マシンのさまざまな「状態」を State サブクラスとして表します。
• Context クラスには、ステート マシンの状態が変化すると変化する現在の状態へのポインターがあります。

状態パターンは、新しい状態への遷移条件が正確にどこで決定されるかを定義しません。 Context クラスまたは State サブクラスの 2 つのオプションがあります。 後者のオプションの利点は、新しい派生クラスを簡単に追加できることです。 欠点は、各 State サブクラスが新しい状態に移行するために隣接するサブクラスについて認識する必要があり、サブクラス間に依存関係が生じることです。

入力データを状態間の遷移に一意にマッピングするテーブルの使用に基づいて、有限状態マシンを設計する別のテーブルベースのアプローチもあります。 ただし、このアプローチには欠点があります。トランジションの実行時にアクションの実行を追加するのが難しいということです。 状態パターンのアプローチでは、(データ構造の代わりに) コードを使用して状態間の遷移を行うため、これらのアクションを簡単に追加できます。

状態パターンの構造

Context クラスは、クライアントの外部インターフェイスを定義し、State オブジェクトの現在の状態への参照を保存します。 抽象基本クラス State のインターフェイスは、1 つの追加パラメーター (Context インスタンスへのポインター) を除いて Context インターフェイスと同じです。 状態派生クラスは、状態固有の動作を定義します。 Context ラッパー クラスは、受信したすべてのリクエストを「現在の状態」オブジェクトに委任します。このオブジェクトは、受信した追加パラメーターを使用して Context インスタンスにアクセスできます。

State パターンを使用すると、オブジェクトの内部状態に応じて動作を変更できます。 自動販売機の動作でも同様の状況が観察されます。 マシンは、商品の入手可能性、受け取ったコインの量、両替機能などに応じてさまざまな状態になることがあります。 購入者が製品を選択して支払いを行った後、次のような状況 (状態) が考えられます。

• 商品を購入者に渡します。小銭は必要ありません。
• 購入者に商品と小銭を渡します。
• 十分なお金がないため、購入者は商品を受け取ることができません。
• 購入者は不在のため商品を受け取ることができません。

状態パターンの使用

• クライアントが「ステート マシン」として使用する既存の Context ラッパー クラスを定義するか、新しい Context ラッパー クラスを作成します。
• Context クラスのインターフェイスを複製する基本 State クラスを作成します。 各メソッドは追加パラメータを 1 つ取ります。それは Context クラスのインスタンスです。 State クラスは、便利な「デフォルト」動作を定義できます。
• 考えられるすべての状態に対して状態派生クラスを作成します。
• Context ラッパー クラスには、現在の状態オブジェクトへの参照があります。
• Context クラスは、クライアントから受信したすべてのリクエストを「現在の状態」オブジェクトに単純に委任し、Context オブジェクトのアドレスが追加パラメータとして渡されます。
• このアドレスを使用して、State クラスのメソッドは、必要に応じて Context クラスの「現在の状態」を変更できます。

Stateパターンの特徴

• 状態オブジェクトは多くの場合シングルトンです。
• Flyweight は、State オブジェクトをいつどのように分割できるかを示します。
• Interpreter パターンは、State を使用して解析コンテキストを定義できます。
• State パターンと Bridge パターンは同様の構造を持っていますが、Bridge ではエンベロープ クラス (「ラッパー」クラスの類似物) の階層が許可されるのに対し、State では許可されない点が異なります。 これらのパターンは類似した構造を持っていますが、解決する問題は異なります。状態ではオブジェクトがその内部状態に応じて動作を変更できるのに対し、ブリッジでは抽象化がその実装から分離されているため、相互に独立して変更できます。
• State パターンの実装は、Strategy パターンに基づいています。 違いはその目的にあります。

Stateパターンの実装

2 つの可能な状態と 2 つのイベントを持つ有限状態マシンの例を考えてみましょう。

＃含む 名前空間 std を使用します。 class Machine ( class State *current; public: Machine(); void setCurrent(State *s) ( current = s; ) void on(); void off(); ); class State ( public: virtual void on(Machine *m) ( cout<< " already ON\n"; } virtual void off(Machine *m) { cout << " already OFF\n"; } }; void Machine::on() { current->(これ); ) void Machine::off() ( current->off(this); ) class ON: public State ( public: ON() ( cout<< " ON-ctor "; }; ~ON() { cout << " dtor-ON\n"; }; void off(Machine *m); }; class OFF: public State { public: OFF() { cout << " OFF-ctor "; }; ~OFF() { cout << " dtor-OFF\n"; }; void on(Machine *m) { cout << " going from OFF to ON"; m->setCurrent(new ON()); これを削除します。 ) ); void ON::off(Machine *m) ( cout<< " going from ON to OFF"; m->setCurrent(新しいOFF()); これを削除します。 ) Machine::Machine() ( current = new OFF(); cout<< "\n"; } int main() { void(Machine:: *ptrs)() = { Machine::off, Machine::on }; Machine fsm; int num; while (1) { cout << "Enter 0/1: "; cin >>番号; (fsm.*ptrs)(); ))

15.02.2016
21:30

State パターンは、複数の独立した論理状態を持つクラスを設計することを目的としています。 早速例に入ってみましょう。

Web カメラ コントロール クラスを開発しているとします。 カメラは次の 3 つの状態になります。

1. 初期化されていません。 これを NotConnectedState と呼びましょう。
2. 初期化され準備完了ですが、フレームはまだキャプチャされていません。 ReadyState にしておきます。
3. アクティブなフレーム キャプチャ モード。 ActiveState と表します。

ここでは状態パターンを使用しているため、状態図のイメージから始めるのが最善です。

では、この図をコードに変換してみましょう。 実装が複雑にならないように、Web カメラを操作するコードは省略しています。 必要に応じて、適切なライブラリ関数呼び出しを自分で追加できます。

最小限のコメントを付けて完全なリストをすぐに提供します。 次に、この実装の重要な詳細について詳しく説明します。

＃含む #define DECLARE_GET_INSTANCE(ClassName) \ static ClassName* getInstance() (\ static ClassName インスタンス;\ return \ ) class WebCamera ( public: typedef std::string Frame; public: // *********** *************************************** // 例外 // ****** ********************************************* クラス NotSupported: パブリック標準: :Exception ( ); public: // ***************************************** ******* ********* // 州 // ***************************** ******* ************** class NotConnectedState; class ReadyState; class ActiveState; class State ( public: virtual ~State() ( ) virtual void connect(WebCamera*) ( throw NotSupported(); ) virtual voiddetach(WebCamera* cam) (std::cout<< "Деинициализируем камеру..." << std::endl; // ... cam->ChangeState(NotConnectedState::getInstance()); ) virtual void start(WebCamera*) ( throw NotSupported(); ) virtual void stop(WebCamera*) ( throw NotSupported(); ) virtual Frame getFrame(WebCamera*) ( throw NotSupported(); ) protected: State() ( ) ); // *********************************************** ** class NotConnectedState: public State ( public: DECLARE_GET_INSTANCE(NotConnectedState) void connect(WebCamera* cam) ( std::cout<< "Инициализируем камеру..." << std::endl; // ... cam->ChangeState(ReadyState::getInstance()); ) void connect(WebCamera*) ( throw NotSupported(); ) private: NotConnectedState() ( ) ); // *********************************************** ** class ReadyState: public State ( public: DECLARE_GET_INSTANCE(ReadyState) void start(WebCamera* cam) ( std::cout<< "Запускаем видео-поток..." << std::endl; // ... cam->ChangeState(ActiveState::getInstance()); ) プライベート: ReadyState() ( ) ); // *********************************************** ** class ActiveState: public State ( public: DECLARE_GET_INSTANCE(ActiveState) void stop(WebCamera* cam) ( std::cout<< "Останавливаем видео-поток..." << std::endl; // ... cam-> << "Получаем текущий кадр..." << std::endl; // ... return "Current frame"; } private: ActiveState() { } }; public: explicit WebCamera(int camID) : m_camID(camID), m_state(NotConnectedState::getInstance()) { } ~WebCamera() { try { disconnect(); } catch(const NotSupported& e) { // Обрабатываем исключение } catch(...) { // Обрабатываем исключение } } void connect() { m_state->接続(これ); ) void cancel() ( m_state->disconnect(this); ) void start() ( m_state->start(this); ) void stop() ( m_state->stop(this); ) Frame getFrame() ( return m_state ->getFrame(this); ) private: void changeState(State* newState) ( m_state = newState; ) private: int m_camID; 状態* m_state; );

DECLARE_GET_INSTANCE マクロに注目してください。 もちろん、C++ でマクロを使用することはお勧めできません。 ただし、これはマクロがテンプレート関数の類似物として機能する場合に当てはまります。 この場合、常に後者を優先してください。

私たちの場合、マクロは の実装に必要な静的関数を定義することを目的としています。 したがって、その使用は正当であると考えられます。 結局のところ、コードの重複を減らすことができ、深刻な脅威を引き起こすことはありません。

State クラスをメイン クラス WebCamera で宣言します。 簡潔にするために、すべてのクラスのメンバー関数のインライン定義を使用しました。 ただし、実際のアプリケーションでは、宣言と実装を h および cpp ファイルに分離することに関する推奨事項に従うことをお勧めします。

状態クラスは WebCamera 内で宣言されるため、そのクラスのプライベート フィールドにアクセスできます。 もちろん、これにより、これらすべてのクラス間に非常に緊密な接続が作成されます。 しかし、州は非常に特殊であることが判明したため、他の状況で再利用することは問題外です。

状態クラスの階層の基礎は、抽象クラス WebCamera::State: です。

クラス状態 ( public: virtual ~State() ( ) virtual void connect(WebCamera*) ( throw NotSupported(); ) virtual voiddetach(WebCamera* cam) ( std::cout<< "Деинициализируем камеру..." << std::endl; // ... cam->ChangeState(NotConnectedState::getInstance()); ) virtual void start(WebCamera*) ( throw NotSupported(); ) virtual void stop(WebCamera*) ( throw NotSupported(); ) virtual Frame getFrame(WebCamera*) ( throw NotSupported(); ) protected: State() ( ) );

そのメンバー関数はすべて、WebCamera クラス自体の関数に対応します。 直接委任が発生します。

Class WebCamera ( // ... void connect() ( m_state->connect(this); ) void Connect() ( m_state->disconnect(this); ) void start() ( m_state->start(this); ) void stop() ( m_state->stop(this); ) Frame getFrame() ( return m_state->getFrame(this); ) // ... State* m_state; )

重要な機能は、State オブジェクトが、それを呼び出す WebCamera インスタンスへのポインターを受け入れることです。 これにより、任意の数のカメラに対して、State オブジェクトを 3 つだけ持つことができます。 この可能性は、Singleton パターンを使用することで実現されます。 もちろん、この例の文脈では、これによって大きな利益が得られるわけではありません。 しかし、このテクニックを知っていることは依然として役に立ちます。

WebCamera クラス自体は、事実上何も行いません。 彼は完全に州に依存しています。 そして、これらの国家は、作戦を実行するための条件を決定し、必要なコンテキストを提供します。

ほとんどの WebCamera::State メンバー関数は独自の WebCamera::NotSupported をスローします。 これは完全に適切なデフォルトの動作です。 たとえば、すでに初期化されているカメラを初期化しようとすると、ごく自然に例外が発生します。

同時に、WebCamera::State::disconnect() のデフォルト実装を提供します。 この動作は、3 つの状態のうち 2 つに適しています。 その結果、コードの重複が防止されます。

状態を変更するには、プライベート メンバー関数 WebCamera::changeState() を使用します。

Void changeState(State* newState) ( m_state = newState; )

次に、特定の状態の実装に移ります。 WebCamera::NotConnectedState の場合は、connect() 操作とdisconnect() 操作をオーバーライドするだけで十分です。

クラス NotConnectedState: public State ( public: DECLARE_GET_INSTANCE(NotConnectedState) void connect(WebCamera* cam) ( std::cout<< "Инициализируем камеру..." << std::endl; // ... cam->ChangeState(ReadyState::getInstance()); ) void connect(WebCamera*) ( throw NotSupported(); ) private: NotConnectedState() ( ) );

州ごとに 1 つのインスタンスを作成できます。 これは、プライベート コンストラクターを宣言することで保証されます。

提示された実装のもう 1 つの重要な要素は、成功した場合にのみ新しい状態に移行することです。 たとえば、カメラの初期化中に障害が発生した場合、ReadyState に入るには早すぎます。 主なアイデアは、カメラの実際の状態 (この場合) と State オブジェクトの間の完全な対応です。

これでカメラの準備は完了です。 対応する WebCamera::ReadyState State クラスを作成しましょう。

クラス ReadyState: public State ( public: DECLARE_GET_INSTANCE(ReadyState) void start(WebCamera* cam) ( std::cout<< "Запускаем видео-поток..." << std::endl; // ... cam->ChangeState(ActiveState::getInstance()); ) プライベート: ReadyState() ( ) );

準備完了状態から、アクティブなフレーム キャプチャ状態に入ることができます。 この目的のために、start() オペレーションが提供されており、これを実装しました。

ついに、カメラの最後の論理状態、WebCamera::ActiveState に到達しました。

クラス ActiveState: public State ( public: DECLARE_GET_INSTANCE(ActiveState) void stop(WebCamera* cam) ( std::cout<< "Останавливаем видео-поток..." << std::endl; // ... cam->ChangeState(ReadyState::getInstance()); ) フレーム getFrame(WebCamera*) ( std::cout<< "Получаем текущий кадр..." << std::endl; // ... return "Current frame"; } private: ActiveState() { } };

この状態では、 stop() を使用してフレームのキャプチャを停止できます。 その結果、WebCamera::ReadyState に戻ります。 さらに、カメラのバッファーに蓄積されたフレームを受信できます。 簡単にするために、「フレーム」とは通常の文字列を意味します。 実際には、これはある種のバイト配列になります。

これで、WebCamera クラスを操作する典型的な例を書き留めることができます。

Int main() ( WebCamera cam(0); try ( // カメラは NotConnectedState cam.connect(); // カメラは ReadyState cam.start(); // カメラは ActiveState std::cout<< cam.getFrame() << std::endl; cam.stop(); // Можно было сразу вызвать disconnect() // cam в Состоянии ReadyState cam.disconnect(); // cam в Состоянии NotConnectedState } catch(const WebCamera::NotSupported& e) { // Обрабатываем исключение } catch(...) { // Обрабатываем исключение } return 0; }

結果として、コンソールに次のように出力されます。

カメラを初期化します... ビデオ ストリームを開始します... 現在のフレームを取得します... 現在のフレーム ビデオ ストリームを停止します... カメラの初期化を解除します...

次に、エラーを引き起こしてみましょう。 connect() を 2 回続けて呼び出してみましょう。

Int main() ( WebCamera cam(0); try ( // カメラは NotConnectedState にあります cam.connect(); // カメラは ReadyState にあります // ただし、この状態では connect() 操作は提供されません! cam.connect( ); // 例外をスローします NotSupported ) catch(const WebCamera::NotSupported& e) ( std::cout<< "Произошло исключение!!!" << std::endl; // ... } catch(...) { // Обрабатываем исключение } return 0; }

そこから出てくるものは次のとおりです。

カメラを初期化しています...例外が発生しました!!! カメラの初期化を解除しましょう...

カメラはまだ初期化されていないことに注意してください。 WebCamera デストラクターで切断() 呼び出しが発生しました。 それらの。 オブジェクトの内部状態は完全に正しいままです。

結論

状態パターンを使用すると、状態図をコードに一意に変換できます。 一見すると、実装は冗長であることがわかりました。 ただし、メイン クラス WebCamera を操作する場合に考えられるコンテキストを明確に分けることができました。 その結果、個々の州を記述する際に、狭いタスクに集中することができました。 これは、明確で理解しやすく信頼性の高いコードを記述するための最良の方法です。