かぶだいくん C# 化

コマンドの実装を整備している。SMBCフレンド証券とオリックス証券用に、画面の状態遷移をうまく制御するのにコツが要る。いろいろ試行錯誤している内に、結構うまくいくやりかたを見つけた。
図で描けば分かりやすいが、面倒なので字だけで説明する。まず、状態遷移のグラフとして、ノードが画面(注文照会画面や保有銘柄一覧画面や、買いの銘柄コード入力画面、などなど)とし、エッジ(アーク)の両端が HTTP request と HTTP response のようなものを考える。エッジの矢印の後方(backward 側)が request で前方(forward 側)が response になる。
たとえば、コマンドAが買いコマンドで、コマンドBが売りコマンドだった場合、コマンドA→コマンドBの順で実行するとすると、コマンドAが遷移する最後の終着点のノードは「買いの受付完了画面」みたいなものになる。その後に、コマンドBが処理される際に、コマンドBはコマンドAが残した「買いの受付完了画面」のノードから開始となるわけだ。コマンドBは、この画面から、「保有銘柄一覧画面」のようなノードに遷移してしまい、あとは売りのシーケンスにおいて、「買いの受付完了画面」に遭遇することはないはず。遭遇したらなんか状態遷移がおかしくなっているということだ。だからコマンドBにおいて、「買いの受付完了画面」に遭遇する可能性があるのは、そのひとつのコマンドの中で遷移するノードの内、最初のノードかどうかで「買いの受付完了画面」を処理すべきかエラーとしてはじくべきかが決まると考えて良い。
要は、コマンドの中での画面遷移において、最初の画面は特別扱いするということ。
もちろん、やりかたとしては、コマンドAは、最後の「買いの受付完了画面」から「トップ画面」のような共通の画面に遷移させておくような後始末をちゃんとやる(クリーンアップする)ような決めにしておくというのもある。こうしておけばコマンドBは常に「トップ画面」からスタートすれば良いので楽である。しかし、これはコマンドAが確実にクリーンアップしてくれることに頼ってしまっているので、コマンドAでコケた場合に、コマンドBにまで影響が及んでしまう。どうせコマンドAがコケることも対処するならば、コマンドAがクリーンアップするよりも、コマンドBがどんな画面からでも開始できるような構造にしておくほうが良いと思う。