Vapor Trail

明るく楽しく元気よく

『Head First オブジェクト指向設計』第7章

第7章 アーキテクチャ

アーキテクチャとは、設計の構造であり、アプリケーション内において重要である部分とそれらの重要部分間での関係に着目する。

アーキテクチャとは、システムの組織化された構造である。各部分への分割、部分間の接続、相互作用メカニズム、システムの設計時に使用される原則と決定が含まれる。

ユースケースとFeatureを作成したがどこから開始すべきか

  • 一番重要なFeatureを選択する
    システムにとって最も重要であると思える事柄から作業を開始するようにすれば良いスタートを切れる。
    Featureはシステムが行わなければいけない機能を表現している。
    アプリケーションにおいて、本当に重要である事柄はアーキテクチャ的に意味のある部分なので、最初に着目すべきである。

  • 重要なFeatureかどうかの判断
    そのFeatureは システムの本質(最も基本的なレベルでシステム内に存在するもの) の一部であるか。
    このFeatureを実装しなくても、システムは必要とする処理を行えるかどうかを問いかける。
    そのFeatureが存在しないシステムを想像できなければ、システムの中核である可能性が高い。

ゲームシステムワーク Feature一覧
1. 様々な地形をサポートする。
2. 様々な時間軸をサポートする。
3. ゲームごとに異なる複数の種類の軍隊やユニットをサポートする。
4. 作戦や戦闘を追加するための、アドオンモジュールをサポートする。
5. 正方形のマスで構成される盤を1枚提供し、各マスには地形が存在する。
6. 誰のターンであるかを制御する。
7. 基本的な移動を管理する。

リスク軽減

主要なFeature 主要なリスク
ゲームの盤 - システムの本質 システムの中核となるFeatureがかけてしまうと顧客がシステムに満足しないというリスク。
ゲーム固有のユニット - 本質とどのような意味であるか Featureの意味がわからないので手戻りや修正が発生し納期を守れなくなるリスク。
移動の管理 - その意味と実行方法 実行方法が明確ではないので、実現できないか長い時間を要するかもしれないというリスク。

主要なFeatureのどこから手を付けるべきか?
これらのFeatureがアーキテクチャ的に意味がある理由はすべてプロジェクトにリスクをもたらすから。

ここで重要なのはどのFeatureに最初に取り組むべきかではなくリスクを軽減させること。詳細が不明な現在の段階ではリスクの軽減に役立たないFeatureに注意をそらしてはいけない。

シナリオ

  • [x] システムの本質であり一番大きいリスクを持つゲームの盤から着手する。

シナリオを作成しBoardモジュールの基本的な部分のみを作成する。
シナリオとは、ユースケースにおいて最初から最後までステップが揃っているパスのこと。

Boardのシナリオ
ゲームデザイナーが高さを幅を指定して盤を作成する。
プレイヤー2が戦車を(4,5)に移動する。
プレイヤー2が軍を(4,5)に移動する。
プレイヤー1が砲兵を(4,5)に移動する。
ゲームが(4,5)にあるユニットを要求する。
プレイヤー1がプレイヤー2と戦闘する。
ゲームが(4,5)の地形を要求する。
  • なぜユースケースを作成しないのか?
    主要Featureの概要が明確になり大きなリスクに対処できたら各モジュールに詳細を追加していく。

次にどのFeatureに取り組むべきか

BoardとUnitには関係があり、ゲーム固有のユニットは主要なFeatureなので、Unitモジュールに取り組む。 - [x] ゲーム固有のユニット - 本質とどのような意味であるか

ゲーム固有にユニットには、属性と能力が異なる様々な種類のユニットが存在する。ゲームごとに異なるプロパティをユニットが保持し、複数のデータ型のプロパティをサポートする必要がある。

共通性と変動性を見つける

  • 共通性
    共通なのはユニットには種類があり、プロパティの集合を保持すること。

  • 解決策1

  • 解決策2

第5章の楽器クラスとよく似ている。解決策1の場合、ユニットの種類ごとにサブクラスが必要になる。 解決策2の場合、Unitクラスが1つあれば異なる種類のユニットをいくつでもサポートできる。

  • よい設計は常にリスクを軽減させる。
    Unitクラスの設計がよければ、Unitクラスを劇的に変更しても他のコードに影響と与えることがなくなる。 プロジェクトの途中・終了間近になって、Unitクラスが変更されても他のクラスのコードを変更する心配をしなくてよい。

Featureの意味がわからないとき

  • [ ] 移動の管理 - その意味と実行方法 Featureの意味が定かでないとき、行えることの1つは顧客に尋ねること。

  • 顧客に尋ねる

  • 共通性分析
  • 実装計画

  • 顧客に質問するのは本当に良いことなのでしょうか?横道に逸れてしまう事態にならないでしょうか?

    作成しているのは顧客のシステムなので、顧客に質問するのは通常よいことです。しかし、質問する側が取り組むべきことをきちんと把握していないと、顧客の言葉に惑わされ、間違ったことに向かってしまうこともたしかにあります。目標が何であるかを明確にするために会話を行い、具体的な内容に対して質問すれば混乱や逸脱を招くような事柄はうまく避けることができるでしょう。

  • 移動の管理とは・・・
    ユニットごとに移動プロパティがあり、移動可能なマスの数が指定される。ゲームの地形を確認して、その移動が行えるかを判定する。

  • 共通性分析

共通するもの 変動するもの
移動が可能であるかのチェックが移動の前に行われる。 移動が可能であるかを判定するアルゴリズムはゲームごとに異なる
ユニットのプロパティが移動距離の計算に使用される。 使用されるプロパティの種類と数はゲームごとに異なる。
ユニット以外の要因が移動に影響する。 移動に影響する要因はゲームごとに異なる。

「ゲームごとに異なる」というフレーズが何回も登場することが明らかになる。
→移動の処理はフレームワークの処理から外し、ゲームデザイナーに自分で処理させるほうが有益であると判断した。

まとめ

  • プロジェクトにとって、システム内の最重要Featureがアーキテクチャ的に意味を持つ。
  • システムの本質であるFeature、意味が曖昧なFeature、実装方法が明確ではないFeatureに最初に着目する。
  • プロジェクトのアーキテクチャ段階で行うべきことはすべてプロジェクトが失敗するリスクを減少させるべきである。
  • Featureの内容がわからなければ、顧客に尋ね、その答えを一般化することで、Featureの正しい理解につなげるべきである。
  • 柔軟なソフトウェアを構築するために、共通性分析を使用する。