詳細設計の成果物は、詳細クラス図。
実装に必要な、すべてのクラス、属性、操作が定義されている完成バージョン。
詳細クラス図は、ユースケース記述を元にシーケンス図を描きながら、丁寧に実装方法を検討しているはず。だから、ワーキングソフトウェアを作る準備が整っている。
ここでモデリングツールの「コード生成」ボタンを押して、コードのテンプレートと作って、コード書きモードに突入することは可能。
プレファクタリング
コードを書いて、動くことを確認し、それから、ぎこちない箇所をリファクタリングする、ということは大切な活動です。設計をコードエディタ上でやっているなら、これもひとつのやり方。
しかし、ICONIXプロセスでは、設計は詳細クラス図で具体化する。この段階で、設計の改良をすることは、とてもコストパフォーマンスが高い。
実コードよりクラス図の方が、全体の見通しが良いです。
例えば、
・操作(メソッド)が集中しているクラス
・操作が割り当てられていないクラス( setter/getter だけのクラス)
・一つの操作だけの手続きオブジェクト
などが簡単に見つかります。
どれも典型的なアンチパターン。設計の改良を検討すべき兆候です。
コードを書いてからメソッドの移動を検討するより、この段階で、操作の割当クラスを検討したほうが、分かりやすいし、作業量も少なくてすみます。
リファクタリング(設計の改善)は、別に、コードを書き終わるまで先送りする必要はありませんよね。
プレファクタリングをしましょう。 ICONIXプロセスでは、詳細なクラス図が完成しているんですから。
カプセル化
詳細クラス図のレビューでは、
・関連するデータと操作が一つのクラスにカプセル化する
・関係の弱いデータや操作は、別のクラスに分離してカプセル化する
を丁寧に検討する。
もちろん、ドメイン(問題領域)の知識は、ドメインオブジェクトにカプセル化すること。
また、一つの大きなドメインオブジェクトではなく、密接に関連するデータと操作だけに絞り込んで小さくカプセル化したオブジェクトが連携して、協調動作するように設計する。
一つの手続きだけをカプセル化した手続きオブジェクト(名前が、 XXX-er とかになっていることが多い)は、どこかのクラスの操作に割り当てるべきではないかと、検討する。
・関連するデータと操作だけを厳選してひとかたまりにする
・関係の弱いデータや操作は、別クラスに分離する(関心の分離)
特に、ドメインオブジェクトへのカプセル化を念入りに検討しましょう。
カプセル化の原則を徹底することが、理解しやすく、変更が安全で容易なクラスを設計するコツです。
ここで、面倒がると、コードは、破綻への道に進み始めます。最初はゆっくりですが、あっという間に加速して、保守地獄にまっさかさまです。
カプセル化、とくにドメインの知識をドメインオブジェクトにカプセル化することに、時間とエネルギーを使いましょう。
詳細設計レビューの今こそ、最大で最後のチャンスです。
実装に必要な、すべてのクラス、属性、操作が定義されている完成バージョン。
詳細クラス図は、ユースケース記述を元にシーケンス図を描きながら、丁寧に実装方法を検討しているはず。だから、ワーキングソフトウェアを作る準備が整っている。
ここでモデリングツールの「コード生成」ボタンを押して、コードのテンプレートと作って、コード書きモードに突入することは可能。
プレファクタリング
コードを書いて、動くことを確認し、それから、ぎこちない箇所をリファクタリングする、ということは大切な活動です。設計をコードエディタ上でやっているなら、これもひとつのやり方。
しかし、ICONIXプロセスでは、設計は詳細クラス図で具体化する。この段階で、設計の改良をすることは、とてもコストパフォーマンスが高い。
実コードよりクラス図の方が、全体の見通しが良いです。
例えば、
・操作(メソッド)が集中しているクラス
・操作が割り当てられていないクラス( setter/getter だけのクラス)
・一つの操作だけの手続きオブジェクト
などが簡単に見つかります。
どれも典型的なアンチパターン。設計の改良を検討すべき兆候です。
コードを書いてからメソッドの移動を検討するより、この段階で、操作の割当クラスを検討したほうが、分かりやすいし、作業量も少なくてすみます。
リファクタリング(設計の改善)は、別に、コードを書き終わるまで先送りする必要はありませんよね。
プレファクタリングをしましょう。 ICONIXプロセスでは、詳細なクラス図が完成しているんですから。
カプセル化
詳細クラス図のレビューでは、
・関連するデータと操作が一つのクラスにカプセル化する
・関係の弱いデータや操作は、別のクラスに分離してカプセル化する
を丁寧に検討する。
もちろん、ドメイン(問題領域)の知識は、ドメインオブジェクトにカプセル化すること。
また、一つの大きなドメインオブジェクトではなく、密接に関連するデータと操作だけに絞り込んで小さくカプセル化したオブジェクトが連携して、協調動作するように設計する。
一つの手続きだけをカプセル化した手続きオブジェクト(名前が、 XXX-er とかになっていることが多い)は、どこかのクラスの操作に割り当てるべきではないかと、検討する。
・関連するデータと操作だけを厳選してひとかたまりにする
・関係の弱いデータや操作は、別クラスに分離する(関心の分離)
特に、ドメインオブジェクトへのカプセル化を念入りに検討しましょう。
カプセル化の原則を徹底することが、理解しやすく、変更が安全で容易なクラスを設計するコツです。
ここで、面倒がると、コードは、破綻への道に進み始めます。最初はゆっくりですが、あっという間に加速して、保守地獄にまっさかさまです。
カプセル化、とくにドメインの知識をドメインオブジェクトにカプセル化することに、時間とエネルギーを使いましょう。
詳細設計レビューの今こそ、最大で最後のチャンスです。