United Front 2　の設計方針

United Front 2 はゲームという性質上、内部構造が非常に複雑化します。複雑さに対応するための手段として、 オブジェクト指向設計、契約による設計、依存性の注入などの手法が挙げられます。

POJO を中心とするオブジェクト指向設計

United Front 2 では、オブジェクト指向プログラミング を中心としたアーキテクチャを採 用しています。単に継承やポリモフィズムといったオブジェクト指向プログラミングの機能を使うというだけではなく、振る 舞いとデータの両方をカプセル化したオブジェクトモデル群を構成することで、単一責任の原則 を守った凝縮度の高いシステムを構築可能にしています。また、オブジェクト指向設計における種々のデザインパターン を適用しやすくするために、中核となるクラスは POJO (Plain Old Java Object) で設計していま す。データアクセス可能な POJO のドメインモデルは、軽量でありながら高機能です。

詳しくは ドメイン層 を参照

テストと一体化した契約による設計

United Front 2 では、全面的に 契約による設計 を採用しています。契約による設計は 信頼性の高いソフトウェアを構築するための優れた手法です。契約による設計では、クラス間の関係は互いの権利と義 務を表す正式な同意であると見なし、クラス同士が結んだ契約は 表明 という形で定義されま す。Java においては、表明の実装として assert 文が用意されていますが、この使用はそれほ ど一般的ではないようです。そこで United Front 2 では、表明を JavaDoc 中に記述し、それを検証する JUnit テストコードを作成することで契約による設計を実装して います。これにより、契約による設計という一貫した方式で実装された高品質で再利用可能なテストが、システム全体 を通して適用されることになります。

詳しくは 契約による設計 を参照

DI コンテナを使った依存性の注入

システムの構成管理には Spring Framework の DI コンテナ を使っています。United Front 2 アプリケーションは非常に複雑な構 造を持つことになりますが、この複雑さは DI コンテナによって実行時に構成されます。単独の Java コードは実行時 に生じるような依存の連鎖から分離されることになるため、独立性が増し、軽量で設計しやすく、テストしやすいクラスに なります。依存性の注入は上述のオブジェクト指向設計や契約による設計を実現する上で重要な手法になります。な お、DI コンテナ以外でも、United Front 2 では一貫して Spring 製品を採用しています。

参考文献

United Front 2 のアーキテクチャが参考としている文献をいくつか挙げておきます。必要に応じて参照してください。