Creating Flexible Interfaces

抜粋

第3章で頻繁に変更が起こるクラスに依存するのは危険という話があったが、この考え方はクラス内の範囲でも同じように適応できる。

クラスの持つパブリックなインターフェースは、そのクラスが持つ責任をドキュメントの役割を果たすべき。

設計をする段階のクラス候補として上がってくる、顧客、旅行、バイクなどのクラスはドメインオブジェクトと呼ばれている。

ドメインオブジェクトはほぼ必ず必要となるものだが、アプリケーション内のすべての振る舞いをこれらのクラスに定義しようとするのは危険。

設計の達人は、ドメインオブジェクト自体だけではなく、ドメインオブジェクト間で発せられるメッセージにフォーカスして、ドメインオブジェクト以外にどのようなクラスが必要になってくるかを見極める。

Ask for "What" instead of Telling "How"

シーケンス図はクラスベースデザインの視点からメッセージベースデザインの視点へ切り替えるためのツールとも言える。

上記の視点の変換は下記のような会話で表せる。

'このクラスは必要だね、何をすべきかな？' から 'このメッセージを送る必要があるんだけど、誰が受け取るべき？'

感想

シーケンス図を使ってメッセージに焦点を当てて設計を考えるというのは早速試してみたいと思った。

UMLを資料としてではなく、設計を考える際の使い捨てのツールとして使う考えも活用させていきたい。