クラス図→ソース

くだらない質問かもしれませんが・・・

まず特急列車などの指定席の予約などを行う簡易プログラムを作りたい時に、
例えば、
◇-- は集約の関連　を表すとして、


受付 ◇-- 時刻表 ◇-- 列車

という部分を持つクラス図を作ったとします。時刻表は列車の発車時刻などが書かれています。（例えばなので、これは集約にすべきじゃない！とかは無しの方向で）


これをソースに書き出してやる際に、
受付クラスは　フィールドとして時刻表への参照配列をもち、時刻表クラスはフィールドとして列車への参照配列をもつとします。

時刻表　timetable[];
列車　　train[]

それで、列車にあるメソッド(hogehoge())を受付のあるメソッドで使いたいというときに、おそらく、

this.timetable[x].train[y].hogehoge();

としますよね。

でも、複雑なクラス図になっていくにつれてもし使いたい場所とメソッドとの間が激しく離れている場合は、
aaa.bbb.ccc.ddd.eee.….zzz();
とかなっちゃいますよね。そうならないように設計しろと言われればそれまでなのですが、実際にクラス図→ソースの段階でこういうこと（設計ミス？）が起きてしまうことってよくあるのでしょうか？

また、この例であれば時刻表クラスに列車オブジェクトを取り出すような

Train getTrain()

とかいうメソッドを用意し、受付クラス中のメソッドで、

Train t = timetable.getTrain();

t.hogehoge();

等する方が一般的でしょうか？なにやらうまく説明できないですが、不明な点があればご指摘ください。

No.1 ベストアンサー 回答者： noname#161966 回答日時： 2005/01/19 00:38

図のような関連になる場合は，受付と列車が関連を持たないということが重要です．設計では関連を持つかどうかも重要ですが，関連を持たないかどうかも重要ですよね．なので，受付から列車を直接扱う必要がある場合は設計ミスということです．一応．

そもそも設計で考えるレベルと実装で考えるレベルが違うので（実装に近づくにつれて，より詳細になっていくもの），設計の時には気付かなかった関連が実装時に判明することは良くあることだと思います．そうかといって，良くあっては困るのですが・・・

クラス図が設計を表しているのか，それとも単に概念を表しているのかに注意する必要があると思います．実装する時は割り切ってソースコードを大切にして実装することもありでしょう．どんなに細かくクラス図を書いたところで動くわけじゃありません．
最終的に完成したソースコードを基にクラス図を生成して，設計にフィードバックして成果物とすることも大切です．