【ITニュース解説】Finite State Machines - the Universal Unit of Work

この記事では、システム開発における状態管理の課題と、それを解決するための新しいライブラリ「FSM_API」について解説する。

多くのシステムでは、オブジェクトの状態に応じて処理を変える必要がある。例えば、「ドア」オブジェクトであれば、「開いている」「閉じている」といった状態が考えられる。初心者が陥りやすいのは、これらの状態をBoolean型の変数（True/False）とif文の組み合わせで管理する方法だ。最初はシンプルに見えるが、状態が増えるにつれてコードが複雑化し、メンテナンスが困難になる。

例えば、ドアに「ロックされている」という状態を追加する場合、IsLockedというBoolean変数を追加し、Open()メソッドの中でIsLockedがFalseの場合のみドアを開けるように条件分岐を追加する必要がある。さらに、「壊れている」「スライドドア」「巻き上げドア」といった状態を追加すると、if文がさらに複雑になり、コード全体の見通しが悪くなる。

この問題を解決するために、従来から有限状態機械（FSM: Finite State Machine）というデザインパターンが用いられてきた。FSMでは、状態ごとにクラスを作成し、状態間の遷移を定義することで、状態管理をより構造的に行う。しかし、この方法も、状態が増えるごとにクラスの数が増加し、コード量が多くなるという課題がある。また、特定のフレームワークに依存する場合もあり、汎用性に欠ける。

そこで提案されているのが「FSM_API」というライブラリだ。FSM_APIは、従来のFSMとは異なり、状態と状態遷移をデータとして定義し、それに基づいて状態管理を行う。これにより、コード量を大幅に削減し、状態の追加や変更を容易に行うことができる。

FSM_APIの最大の特徴は、POCO（Plain Old C# Object）と呼ばれる、特別な機能を持たないシンプルなクラスを状態のコンテキストとして使用できる点だ。これにより、FSM_APIのロジックとアプリケーションのデータが完全に分離され、高い柔軟性を実現できる。

記事では、ドアの例を用いてFSM_APIの使用方法を説明している。まず、DoorクラスをPOCOとして定義する。次に、FSM_APIを用いて、「閉じている」「開いている」という状態と、それらの間の遷移を定義する。Transitionメソッドを使用することで、状態間の遷移条件を指定できる。例えば、「閉じている」状態から「開いている」状態への遷移条件として、「ロックされていない」ことを指定できる。

FSM_APIは、1つのコンテキストオブジェクトに対して複数のFSMを定義できる点も特徴だ。これにより、「ドアの開閉」と「ドアのロック」といった、異なる機能を独立して管理できる。

FSM_APIの利点としては、状態管理ロジックの一元化、軽量性、実行時の状態再定義、フレームワークへの非依存性、スレッドセーフ、エラー耐性などが挙げられる。一方、欠点としては、新しい概念を理解する必要があること、APIがミニマルであるためドキュメントを参照する必要があることなどが挙げられている。

FSM_APIは、NuGetパッケージとして提供されており、GitHubリポジトリでドキュメントやサンプルコードを確認できる。