3つのカテゴリ
- 分析クラス、設計クラス、実装クラス
分析クラス
- 外部のシステムのモデルから直接引き出されたデータ抽象
- PLANE、PARAGRAPH、PART 等
実装クラス
- アルゴリズムの内的な必要性から導入されたデータ抽象
- LINKED_LIST、ARRAY 等
設計クラス
- 中間
- アーキテクチャ上の選択
- Undo における COMMAND、パネル駆動式システムの STATE 等
分析クラス/実装クラスと比較した設計クラスの位置付け
- 分析クラス → 問題の領域、実装クラス/設計クラス → 解決策の領域
- 分析クラス/設計クラス → 上位レベル(?)、実装クラス → 下位(?)レベル
「外界」に注目する
- ソフトウェアに関する世界
- いわゆるドメイン/問題領域だと思われる
外界にあるものを分析することで得られた型を使う 問題領域の専門家が使う抽象を使う事で有用なクラスになる確率は高い 問題領域の概念をそのまま取り入れれば良いというわけではない
- 良いクラスは問題領域において価値が持続するが故に選ばれた外界の属性によって(抽象データ型のやり方で)特徴付けられる抽象的な概念に基づいている
「データ構造とアルゴリズム」の教科書は豊富にある
- 実装クラスを引き出すのはそれほど難しくない
- しかし実装するのは難しい
- こまめに参考するべき
理想的はライブラリが既にある事
実装クラスを抽象化した暫定クラス?
洗練され、拡張可能なソフトウェア構造の生成を助けるアーキテクチャの抽象
良い設計クラスを見つける確実な方法は無い
- 多くの場合他の誰かによって考え出されている
- デザインパターン
- 多くはものというよりマシンとして考えた方がよりよく理解できる抽象として表現される
- 再利用の方が望ましい
正しい抽象を見つける為のヒューリスティックス
開発が終わった時点で一般化可能な形にリファクタリングする
解放/閉鎖の原則に従って元クラスはバグ以外は変更しない 代わりに継承をして再定義する
設計を見直す
- 2つのモジュールが密結合過ぎる
- 多くのモジュールと通信している
- 引数リストが長過ぎる
オブジェクト指向以外のシステムで使われるアイデアを参考にクラスを見つける 経験豊富な開発者からアイデアを取り入れる
他のプログラミング言語の例
- Fortran … コモンブロックがクラスに対応しうる
- Pascal/C … レコードがクラスに対応する
- COBOL … Data Division
- ERモデリング … エンティティがクラスに対応しうる
ファイル構造がクラスの構成になりうる 例: passwd、printcap、termcap等
ユースケースとは 「将来のシステムのユーザによって」開始されるイベントと「ユーザと」システムの間のインタラクションの完全な記述
クラスを見つけるのに最適の道具ではない
- ユースケースは順序が重要であるが、オブジェクト指向はこれを避けている
- ユースケースのシステム図は既存のプロセスを元にするが、コンピューターシステムはまだ無いシナリオを考えることになる
- ユースケースはプロセスからのアプローチ、オブジェクト指向はデータ抽象からのアプローチ
- 従来のトップダウンの機能的設計になりがち
ユースケースの原則
- 要するに使うな、という事
ユースケースは分析ツールではなく確認ツール
4インチ×6インチ(A6くらい?)のサイズのカードに Class, Responsibility, Collaboration を書き込む 設計過程への技術的な貢献については不明
- (一時期試したが、個人的にも不明。A6のカードは良い)
22.5.1 ボトムアップの要素
要件定義のフェーズだけで行うのはコストがかかりすぎる 「クラスを見つける」事は作る事ではなく、出くわす事である
22.5.2 クラスの知恵
略
22.6 クラスを手に入れるための手法
表参照