開発者のサービスでの単純なステートマシン

ちょっと普通のプログラマーを想像してみてください。 彼の名前がVasyaであり、ウェブサイト/デスクトップアプリケーション/モバイルアプリでアニメーションメニューを作成する必要があるとします。 WindowsウィンドウのメニューやOS Xのアップルのメニューのように、上から下に移動します。ここにあります。



彼は1つのドロップダウンボックスから始め、アニメーションをテストし、100％のイーズアウトを設定し、結果を楽しんでいます。 しかし、彼はすぐに、メニューを管理するために、現在メニューが閉じられているかどうかを知ることができればいいことに気づきます。 ここでは経験豊富なプログラマであり、フラグを追加する必要があることをすべて理解しています。 質問はありません、フラグがあります。

var opened = false;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

うまくいくようです。 ただし、ボタンをすばやくクリックすると、メニューが点滅し始め、開いたり閉じたりしてから、最終状態に戻ります。 Vasyaはアニメーションフラグを追加します。 コードは次のとおりです。

 var opened = false; var animating = false; function onClick(event) { if (animating) return; if (opened) close(); else open(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しばらくすると、Vasyaはメニューを完全にオフにして非アクティブにできると言われます。 質問なし！ 私たちはここで経験豊富なプログラマーであり、全員が理解しています...もう1つのフラグを追加する必要があります！ そして、開発の数日後、メニューコードはすでに次のような二重行IFで満たされています。

 if (enabled && opened && !animating && !selected && finishedTransition && !endOfTheWorld && ...) { ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Vasyaは質問を開始します。アニメーション化== trueかつ有効化== falseにするにはどうすればよいですか。 なぜすべてが時々バグがあるのですか。 メニューの状態をどのように理解することができますか？ うん！ 状態...それらについてさらに説明します。



このVasyaに会いましょう。

状態

Vasyaは、フラグの多くの組み合わせが意味をなさないことをすでに認識し始めており、残りは、たとえばDisabled 、 Idle 、 Animating 、 Openedのようないくつかの単語で簡単に説明できます。 ここではすべて経験豊富なプログラマであり、ステートマシンについてすぐに覚えています。 しかし、Vasyaは、それが何であり、なぜであるかを説明する必要があります。 数学用語のない単純な言語。



たとえば、前述のメニューなどのオブジェクトがあります。 オブジェクトは常に1つの状態にあり、さまざまなイベントに反応すると、これらの状態間で遷移する可能性があります。 通常、状態、イベント、および遷移はこのようなスキームで簡単に記述されます（初期状態と最終状態は円で示されます）。







この図から、 Inactive状態からActiveに至るまではBeginイベントのみで取得でき、 Paused状態からはActiveとInactiveの両方に到達できることが明らかです。 何らかの理由で、このような単純な概念は「有限状態機械」または「有限状態機械」と呼ばれ、一般の人々にとって非常に怖いものです。



OOP契約によれば、状態はオブジェクトの内部に隠されていなければならず、外部からはアクセスできません。 たとえば、オブジェクトは操作中に20の異なる状態を持つ場合がありますが、外部APIは「元気ですか？」という質問に答え、そのうち19個に「そのようなことはありませ ん」と答え、 すべてのポリマーが故障したことを誓います。



ステートマシンの概念に従って、このオブジェクトまたはそのオブジェクトが何をどのように行うかが常に明確になるように、コードを非常に簡単に構成できます。 システムが突然この状態からアクセスできない状態になろうとした場合、何かがうまくいかなかったことは常に明らかです。 そして、突然間違った時間に来ることを敢えてした出来事は安全に無視することができ、何かが壊れることを恐れることはありません。

世界で最もシンプルなステートマシン

今、VasyaがC＃でプロジェクトを行っており、1種類のオブジェクトに単純なステートマシンが必要だとします。 彼は次のように書いています。

 private enum State { Disabled, Idle, Animating } private State state; void setState(State value) { state = value; switch (state) { case State.Disabled: ... case State.Idle: ... case State.Animating : ... break; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これは現在の状態に応じてイベントを処理する方法です：

 void event1Handler() { switch (state) { case State.Idle: ... break; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、ここで私たちは経験豊富なプログラマーであり、setStateメソッドが最終的に数十ページに成長することを理解しています。これは（教科書に書かれているように）良くありません。

状態パターン

数時間グーグルで調べたVasyaは、このような状況ではState Patternが理想的であると判断しました。 さらに、上級プログラマーは常に競合しており、誰がより多くのパターンをアプリにプッシュするので、Vasyaは、パターンは重要なものであると判断しています。



たとえば、状態パターンの場合、 IStateインターフェイスを作成できます。

 public interface IState { void Event1(); void Event2(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、このインターフェースを実装する状態ごとに個別のクラス。 理論的には、見た目は美しく、教科書の100％です。



しかし、まず、不幸な小さな状態マシンごとに、多くのクラスを作成する必要がありますが、それ自体は高速ではありません。 第二に、遅かれ早かれ、共有データへのアクセスに関する問題が発生します。 それらをどこに保存しますか？ メインクラスでは？ そして、状態クラスはどのようにそれらにアクセスしますか？ そして、締め切りの15分前にルールをバイパスする小さなハックをどうやって取得するのですか？ そして、開発を大幅に遅くする同様の相互作用の問題。

言語ベースの実装

一部のプログラミング言語では、特定の問題を簡単に解決できます。 たとえば、Rubyには、一般にステートマシンを作成するためのDSLがあります（1つではありません）。 C＃では、リフレクションを使用してステートマシンを簡素化できます。 このようなもの ：

1. FiniteStateMachineクラスを継承し、
2. stateName_eventName（）というメソッドを作成します。これは、状態遷移およびイベント処理時に自動的に呼び出されます

書くコードは本当にずっと少ないです。



上記のシステムを実装したVasyaは、プラスよりもマイナスが多いことも理解しています。

• FiniteStateMachineクラスから継承する必要があります。
• カスタムイベントへの反応では、大きなスイッチコンストラクトを記述する必要もあります。
• 状態が変化したときにパラメーターを渡す方法はありません。

枠組み

一方、Vasyaはステートマシンの理論を掘り下げ始め、APIを介して、または理論的にはクールに聞こえるXMLを介してXMLを介して正式に記述できるとよいと判断しました。 ここでは経験豊富なプログラマーであり、独自のフレームワークを作成する必要があることをすべて理解しています。 他の人は適切ではないのは、彼らにはすべて致命的な欠陥があるからです。



Vasyaは、フレームワークの助けを借りて、多くの不必要なコードを記述することなく、ステートマシンを迅速かつ簡単に作成できると判断しました。 フレームワークは、開発者に制限を課しません。 周りは陽気で陽気です。



私はさまざまな言語で多くのフレームワークを試しましたが、自分で似たようなものをいくつか書きました。 そして、常に、フレームワークツールを使用して有限状態マシンを記述するには、 単純な例よりも多くのコードが必要でした。 それらはすべて一定の制限を課しており、多くの人が一度に多くのことをしようとするため、単純なステートマシンの作成方法を理解するために、ドキュメントを長時間調べる必要があります。



たとえば、 ステートレスフレームワークによるステートマシンの説明を次に示します。

 var phoneCall = new StateMachine<State, Trigger>(State.OffHook); phoneCall.Configure(State.OffHook) .Permit(Trigger.CallDialed, State.Ringing); phoneCall.Configure(State.Ringing) .Permit(Trigger.HungUp, State.OffHook) .Permit(Trigger.CallConnected, State.Connected); phoneCall.Configure(State.Connected) .OnEntry(() => StartCallTimer()) .OnExit(() => StopCallTimer()) .Permit(Trigger.LeftMessage, State.OffHook) .Permit(Trigger.HungUp, State.OffHook) .Permit(Trigger.PlacedOnHold, State.OnHold);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、ステートマシンの作成を完了すると、フレームワークが提供する便利な機能を利用できます。 これは主に、遷移の正確性、依存状態マシンとサブ状態マシンの同期、およびばかに対するあらゆる種類の保護のチェックです。

XML

XMLは別の悪です。 かつて誰かがそれを使って設定を書くことを考えました。 java開発者のレミングスの群れが彼のために長い間祈っていました。 そして今、誰もがXMLを使用する理由を誰もまだ知りませんが、それを取り除こうとしているすべての人を打ち負かしています。



Vasyaは、すべてをXMLで構成でき、コードを1行も書かないという考えも持っています！ その結果、そのフレームワークには、およそ次の内容のXMLファイルが個別に含まれます。

 <fsm name="Vending Machine"> <states> <state name="start"> <transition input="nickel" next="five" /> <transition input="dime" next="ten" /> <transition input="quarter" next="start" action="dispense" /> </state> <state name="five"> <transition input="nickel" next="ten" /> <transition input="dime" next="fifteen" /> <transition input="quarter" next="start" action="dispense" /> </state> <state name="ten"> <transition input="nickel" next="fifteen" /> <transition input="dime" next="twenty" /> <transition input="quarter" next="start" action="dispense" /> </state> ... </states> </fsm>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラス！ プログラミングは不要です。 しかし、ここで私たちは経験豊富なプログラマーであり、プログラミングはどこにも行っていないことを皆が理解しています。 Vasyaは、特権コードを宣言コードに置き換え、フレームワークにXMLインタープリターを追加しましたが、それでも数回複雑になりました。 そして、コードが異なる言語であり、プロジェクトのあちこちに散らばっているときに、そらしてみてください。

合意

そして、Vasyaはこれらすべてにうんざりし、世界で最も単純なステートマシンに戻った。 彼はそれを少しやり直し、その中にコードを書くためのルールを思いつきました。



更新： コメントをありがとう。 少し説明がありませんでした。



いくつかの州があります。 それらの間の遷移はアトミック操作のトランザクションです。つまり、それらは常に正しい順序で一緒に発生し、他のコードはそれらの間をくさびで締めることができません。 状態がAからBに変わると、次のことが起こります。状態Aからの終了コードが実行され、状態がAからBに変わり、状態Bのエントリコードが実行されます。



状態Aに切り替えるには、stateAメソッドを呼び出す必要があります。このメソッドは、必要なロジックを実行し、setState（A）を呼び出します。 setState（A）を自分で呼び出すことは非常に推奨されません。



次のことが判明しました。

 /** *    enum   ,     enums. */ private enum State { Disabled, Idle, Animating } /** *    . ,         . */ private State state; /** *         state< >(). *                . *    setState(newValue)     . */ void stateDisabled() { switch (state) { case State.Idle: break; } setState(State.Disabled); // State Disabled enter logic } /** *       . * stateIdle(0); */ void stateIdle(int data) { setState(State.Idle); // State Idle enter logic } void stateAnimating() { setState(State.Animating); // State Animating enter logic } /** *  setState    * state = value; *   prevState = state;     . * ,         . */ void setState(State value) { switch ( state ) { case State.Animating: // state Animating exit logic break; // other states } state = value; } /** *     ,     . */ void event1Handler() { switch (state) { case State.Idle: // state Idle logic break; // other states } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

更新： setState（）には、状態を終了するための固有のロジックが書き込まれ、stateB（）には、Bに移動するときに状態Aを終了するための特定のロジックが使用できます。しかし、非常にまれに使用されます。



ステートマシンを記述するための単純な規則。 非常に柔軟で、次の利点があります。

• 状態を変更するときのほとんどすべてのロジックはstateA（）メソッドにあります。これにより、 setState（）の巨大なスイッチを解除してコードを読みやすくすることができます。
• 状態の変更は、デバッグを容易にするstateA（）メソッドを通じてのみ発生します。
• たとえば、本にページ状態がある場合、 statePage（42）を呼び出して状態を変更するだけで、新しいページに切り替えることができます。
• イベントハンドラーでは、どのロジックがどの状態で実行されるかは常に明確です。
• すべてのチームメンバーは、状態を開始および終了するためのロジックを記述する場所を知っています。
• 有限状態マシンのフレームワークと予備構成は必要ありません。
• ガールフレンドにとって絶対に何でもない場合、最後の瞬間にすべてを汚す可能性があります。

別の非自明な利点は、合意が言語から独立していることです。 あるプラットフォームから別のプラットフォームに移行する場合、お気に入りのフレームワークを別の言語に書き直したり、適切なフレームワークを探したりする必要はありません。



すべての合意にあるように、一部のコードは最初に1つの場所にある場合がありますが、その後、別の意味を持つか、どこかに複製されることが判明します。 その後、別の場所に移動できます。 誰も私たちを禁止していません。 それでも、コードは石で彫られたものではなく、（恐ろしい！）プロジェクトの開発に伴って変更される可能性のあるテキストです。



UPDATE： およびsetState（）は、明確にするために1つのセッターに完全に置き換えることができます。

おわりに

これで、ステートマシンの世界でのVasyaの魅力的な冒険は終わりです。 しかし、まだ非常に興味深いことがあります。 別のトピックでは、パラレルステートマシンと依存ステートマシンに値するだけです。



ステートマシンをまだどこでも使用していない場合は、この記事があなたを良い側に引き寄せることを願っています。 ステートマシンを操作するためのuberframeworkを作成すると、新鮮な外観で得られるものを確認するのに役立ちます。



この記事が、開発者がパターンとフレームワークをどこで、いつ使用するかを考える助けになり、ステートマシンの設計に関する説明された合意が誰かに役立つことを願っています。