LSH構造
MVCパターンの派生として、GipoではLSHという手法を用意しています。
gipo/template以下で具体的な実装方法を参照できます。
MVCのModelにあたります。
プログラムの基本的な処理を担当します。ほとんどの処理がここに入りますが、不確定な要素を入れてはいけません。以下に例を出します。
- ユーザーの入力など、不確定のもの
- 非同期処理など、結果までの時間が不明なもの
- ファイル読み込み、サーバー通信など、外部データを参照する処理
- ランダム（ただし、固定したseedによって生成されるものは除外する）
- 時刻やデバイス情報など環境の情報を得る処理
MVCのViewにあたります。
MVCでは表示のみを担当しますが、LSHではLogicが担当しないもの全てを担当します。このページの最初の図ではSectionという名称で１つだけですが、実際にはViewやService、AssetManager、RandomManagerといった、各機能に合わせた名称で存在し、それら全てを合わせてSectionと呼びます。どれもLogicとの関係性は同じになり、並行で存在します。
アプリケーションの重要な情報や、判断をSectionが行ってはいけません。例えばゲームにおけるキャラクターのxy座標などは、Logicが持ち、それに基いてViewが表示を行います。
SectionはLogicに対してインターフェースを提供することで、その内容を切り替えることが出来ます。例えばゲームの開発時に、非常に簡易な表示PilotViewと、実際の表示ViewImplを用意すると、ViewImplで何らかの問題が発生している時、あるいは起動処理があまりに重い場合でも、PilotViewを使用することでLogicに対する開発を継続することができます。
他にもFileManagerに対してダミーの情報を返すSectionを作り、入れ替えることで、より自由な開発を手助けすることができます。
Gipoフレームワークでは、アプリケーションの開発時にまず、Pilotと呼ばれる内容を満たすだけのSectionを制作し、後から実際のものを開発することを推奨しています。
LogicからSectionへの命令をorderと呼びます。これはインターフェースを介してメソッドを呼び出すだけの動作です。
基本的にはorderの使用を推奨しますが、ゲーム開発では例えば毎フレームxy座標を参照するといった頻繁な処理があり、Logic側からのメソッド呼び出しでは煩雑な記述になってしまうことがあります。その場合はPeekというインターフェースでLogic側の要素を提供するようにします。
Haxeはインターフェースでも細かいアクセス定義が出来るため、有用です。
LogicへはHookを通してEnumでinputを通知します。
inputには2種類あり、すぐにデータが用意できるものをinstant、Section側で何らかの準備が整う必要があるもの（例えば表示画像のロードなど）をReadyと呼びます。
これらの詳細は再現性を参照してください。
MVCのControllerにあたります。
Sectionからの入力をLogicに伝える役割を持ち、コード的には非常に簡素なものになります。再現性という機能を担保するために非常に重要な役割を持っています。再現性については該当ページを参照してください。
SectionからLogicへの全ての入力は、Hookを通す必要があります。