クラスは一通り発見できました。
あとは、クラスが協調して、ユースケースを実現できるように、クラス間のコミュニケーションを設計しなければいけません。
シーケンス図でいえば、メッセージの定義、クラス図だと、操作をクラスへ割当てる、コードへの実装だと、メソッドの定義ですね。
作業は簡単
Enterprise Architect のようなモデリングツールを使えば、これは、一つの作業としてやることができます。
シーケンス図上でメッセージを追加すると、自動的にクラスの操作として追加でき、コードの自動生成機能で Java コードのメソッド宣言のコードを作れます。
最難関
図を描く作業は簡単ですが、設計としては、最も難所にさしかかっています。
どのクラスにどの操作(メソッド)を割り当てるかは、概念ではなく、現実の意思決定だし、その決定がそのまま実装クラスの構造になります。
コードが理解しやすく変更も安全で容易になるか、理解不能で副作用が怖くて変更ができないスパゲティになるかは、ここでの意思決定が分岐点になります。
設計の神髄だし、上級の技術者とかけだしの技術者の腕がもっとも違うところですね。
基本パターンの勉強
操作の割当(メソッドの設計)のパターンは、最近は、勉強すればたくさんの良い情報が手に入ります。
特に、以下の6冊はお薦めです。
レベッカワーフスブラックの オブジェクトデザイン
Eric Evans の Domain-Driven Design (DDD)
Pavel Hruby の ビジネスパターンによるモデル駆動設計
マーチンファウラーのエンタープライズ・アプリケーション・アーキテクチャ・パターン (PoEAA)
同じく リファクタリング
Kent Beckの Implementation Patterns
私は、これらの本で、どういうクラスを、どういう操作(メソッド)を割り当てるかの考え方と基本パターンを勉強しました。
特に、なぜ、こういうパターンが良いか、あるいは、なぜ、こういうパターンは悪いかというという、考え方・判断材料をいろいろ勉強しました。
共通していることは、唯一のベストパターンはない、ということです。何を重視し、何をあきらめるかによって、いろいろパターンがある。
重視すること
私は、基本的には、
・読みやすいコード
を最も重視しています。
・大きなクラス、大量のメソッドを持つクラスは読みにくい。
・長いメソッドは読みにくい
・名前の省略形は読みにくい
・問題領域の言葉(業務用語)中心だとコードの意図が分かりやすい
...
まあ、これだけで意思決定できないケースが多いんですけど、コードの基本価値として、ここにはこだわっている。
実際に、それが、分かりやすく、変更が安全で容易なコードを作ることに効果があがっていると思う。
あとは、クラスが協調して、ユースケースを実現できるように、クラス間のコミュニケーションを設計しなければいけません。
シーケンス図でいえば、メッセージの定義、クラス図だと、操作をクラスへ割当てる、コードへの実装だと、メソッドの定義ですね。
作業は簡単
Enterprise Architect のようなモデリングツールを使えば、これは、一つの作業としてやることができます。
シーケンス図上でメッセージを追加すると、自動的にクラスの操作として追加でき、コードの自動生成機能で Java コードのメソッド宣言のコードを作れます。
最難関
図を描く作業は簡単ですが、設計としては、最も難所にさしかかっています。
どのクラスにどの操作(メソッド)を割り当てるかは、概念ではなく、現実の意思決定だし、その決定がそのまま実装クラスの構造になります。
コードが理解しやすく変更も安全で容易になるか、理解不能で副作用が怖くて変更ができないスパゲティになるかは、ここでの意思決定が分岐点になります。
設計の神髄だし、上級の技術者とかけだしの技術者の腕がもっとも違うところですね。
基本パターンの勉強
操作の割当(メソッドの設計)のパターンは、最近は、勉強すればたくさんの良い情報が手に入ります。
特に、以下の6冊はお薦めです。
レベッカワーフスブラックの オブジェクトデザイン
Eric Evans の Domain-Driven Design (DDD)
Pavel Hruby の ビジネスパターンによるモデル駆動設計
マーチンファウラーのエンタープライズ・アプリケーション・アーキテクチャ・パターン (PoEAA)
同じく リファクタリング
Kent Beckの Implementation Patterns
私は、これらの本で、どういうクラスを、どういう操作(メソッド)を割り当てるかの考え方と基本パターンを勉強しました。
特に、なぜ、こういうパターンが良いか、あるいは、なぜ、こういうパターンは悪いかというという、考え方・判断材料をいろいろ勉強しました。
共通していることは、唯一のベストパターンはない、ということです。何を重視し、何をあきらめるかによって、いろいろパターンがある。
重視すること
私は、基本的には、
・読みやすいコード
を最も重視しています。
・大きなクラス、大量のメソッドを持つクラスは読みにくい。
・長いメソッドは読みにくい
・名前の省略形は読みにくい
・問題領域の言葉(業務用語)中心だとコードの意図が分かりやすい
...
まあ、これだけで意思決定できないケースが多いんですけど、コードの基本価値として、ここにはこだわっている。
実際に、それが、分かりやすく、変更が安全で容易なコードを作ることに効果があがっていると思う。