絶景かな？
頂上から眺めると、見渡す限りの風景の中に、そこにたどり着くまでの道程も見えてきます。ソフトウェア開発でも、完成したプロダクトを眺めるだけでなく、そこにたどり着くまでのプロセスを俯瞰してみると、そこに新たな世界が開けて見えてきます。
今回の設計を俯瞰する
LifeGamePane は、Lifeではなく、インターフェイスを規定したShapeに依存しています。LifeGamePanelが保持する生命体は、Lifeだけとは限りません。Shapeで規定したプロトコルに従うなら何でもかまわないので、より柔軟性に優れたコードを記述できます。この話題については、後の連載で紹介します。
ここで着目して欲しいのは、Shapeを境に、表示の対象となるモデルと、表示を担当するビューとを分断したことです。モデルの立場からは、特定のビューに束縛されたくありません。ビューの立場からは、先の連載第2回で紹介したPuzzlePanelを再利用できたのではと悔やまれます。なぜなら、多くの部分を模倣して作成したからです。
モデルとなるLife/Tileの違いは、クラス自身と結ぶ関連を持つことです。この関連neighborは、隣接する生命体と対話をするのに必要です。
《読者への課題》要求仕様の変更
ライフゲームには、いくつもの変種が存在します。今回は、境界条件を扱うのが学習目的なので、有界にしています。例えば、上下左右の領域を繋げてリング状にすると、閉じた空間を表現できます。左右を捻ってメビウスの環のようにすると、興味深い特徴を観察できます。中空にしたドーナツ状のトーラス面も形成できます。皆さんの理解度を確かめる意味でも、果敢に挑戦してみてください。
おわりに：予告編
アジァイル開発の流儀「1度目は見過ごしても、2度目は見過ごすな」に従うなら、ここはリファクタリングの好機です。後の連載では、パズルゲームとライフゲームに共通する特徴を抽出して、フレームワークを構築する方法を紹介します。これによって、新たなゲーム（オセロゲーム）を作りたいという要求に備えます。
