第5章 後半 良い設計=柔軟なソフトウェア
柔軟ではないコードに対処する
アプリケーションの変更時に問題が発生するのは、ソフトウェアの柔軟性が足りないから。「凝集度」を高めて結合の問題を解決する。
・凝集度と結合度
設計におけるオブジェクトの責務分配に有効なものさし -凝集度と結合度-
問題点
現在の設計
楽器を追加するたびに新しいクラスを作成しなければいけない。
Instrumentクラス(楽器)は概念であり抽象クラスにするべきであるため楽器の種類ごとにサブクラスが必要になる。 またそれぞれの楽器はプロパティをInstrumentSpec(楽器仕様)のサブクラスで表すため、楽器ごとに~Specクラスが必要になる。 これらははじめは良い設計のように思えたが、楽器の種類を追加するたびに新しい仕様クラスを追加するため、あまり仕事をしない大量のクラスが作られることになる。その結果変更が困難になる。
楽器ごとに振る舞いは変わらないのでサブクラスにする必要はなかった。
設計上の間違った決断を正す
- 自分の設計における間違いを消し去ることは難しい
楽器の種類ごとにInstrumentのサブクラスを作ることに意味はなかったが、そのときには意味があるように思えた。
実際に動作しているものを変更することは難しいが、設計が改善されれば長期的には時間が節約される。
設計はイテレーティブであり、他のプログラマーから受け継いだ設計だけでなく、自分で行った設計も、必要に応じて変更できなければいけません。
- 変更点
- 楽器固有のサブクラスの削除
- 楽器が追加されるたびに新しいプロパティをInstrumentSpecに追加しなくてすむように、楽器のプロパティを動的に追加できるように変更。
設計の見直しによって
新しい楽器を追加するたびにサブクラスを作る必要はなく、「製造年」でも検索できるようにしたいと言われても、コードを変更する必要はなくなった。
どうすれば設計が上達するのか
ソフトウェア設計の上達には、実際にソフトウェアを作成することが一番です。GuitarやMandolinクラスを追加するなどの、間違った道に何度も迷い込まないと、行うべき正しいことには気づきませんでした。たいていのよい設計は、悪い設計を経て誕生します。最初から正しい人はほとんどいません。したがって、意味のあることをひたすら行い、オブジェクト指向の原則やパターンを適用して、今まで行ったことを改善できるか確認していくしかないのです。
『Head First オブジェクト指向設計』p255
凝集度
凝集度は、単一のモジュール、クラス、オブジェクトの要素間における接続の程度を測定する。ソフトウェアの凝集度が高ければ、アプリケーション内の各クラスの責務が明確に定義され、関連付けられている。そして、各クラスは特定された密接に関連するアクションを実行する。
- 「高凝集のクラスは1つのことをとてもよく行い、他のことを行おうとはしない。」
- 高凝集のクラスは特定の作業にだけ集中する。
- すべてのメソッドがクラスの名称と関連しているか。場違いに思えるメソッドがあれば、他のクラスに移したほうがよい。
- 高凝集・低結合は、オブジェクトが相互に依存していないため拡張や分割、再利用が容易なソフトウェアにつながる。
