絶景かな？
頂上から眺めると、見渡す限りの風景の中に、そこにたどり着くまでの道程も見えてきます。ソフトウェア開発でも、完成したプロダクトを眺めるだけでなく、そこにたどり着くまでのプロセスを俯瞰してみると、そこに新たな世界が開けて見えてきます。
先の連載で紹介した2つのゲームから、共通するフレームワークを抽出して、それをもとにオセロゲームを作成しました。
GameBoardPanel/OthelloPanelは、GameItem/Stoneではなく、インターフェイスを規定したShapeに依存しています。OthelloPanelが保持するコマは、Shapeで規定したプロトコルに従うなら何でもかまわないので、より柔軟性に優れたコードを記述できます。
ここで着目して欲しいのは、Shapeを境に、表示の対象となるモデルと、表示を担当するビューとを分断しただけではなく、アプリケーションに依存しないフレームワークと、アプリケーションに固有の情報とを分割統治したことです。そのため、GameBoardPanel/GameItem傘下の子孫クラスは、任意の組み合わせが可能です。
インターフェイスShapeを境に、モデル/ビューは相互に独立しているので、盤面OthelloPanelと石Stoneには依存関係がありません。俯瞰図を見ると、モデル/ビューを結ぶ線が描かれていないので、それは明白です。要求仕様を変更しても、相互に及ぼす影響が少なく、各部品を拡張するのも容易です。
明日の扉を開けて
フレームワークを活用するためには、その約束事を正確に把握する必要があります。それには、クラス図を眺めているだけでは分かりません。メソッドのシグニチャーだけではなく、プロトコルに関する正確な情報を収集する必要があります。
クラス図を作成するのが目的ではありません。アプリケーション開発に必要な情報が得られないなら、クラス図も、開発プロセスにとってはただのコメントにすぎません。それは、コメントが、コンパイル/実行時に意味を持たないのと同じ理屈です。クラス図で不足する情報は、OCLで補足したり、本格的な形式手法VDM++を導入したり、さまざまな工夫が提案されています。この話題については、後の連載で紹介します。
花より団子。ただ眺めていても、その味は分かりません。食べたとき（開発時）に初めて、美味しい（有難味が分かる）と言える、そのような品揃え（開発手法）にも気を配りたいものです。
