Head Firstデザインパターン 第2版 ―頭とからだで覚えるデザインパターンの基本

340

 

9

章

単一責務の原則

単一責務の原則

 アグリゲートが内部コレクション、関連する操作、「そして」

反復処理メソッドを実装できるようにすると、どうなるでしょ

うか？

アグリゲート内のメソッド数が増えることはすでにわ

かっていますが、だから何だと言うのでしょうか？

なぜそれが

それほど悪いことなのでしょうか？

 その理由を理解するには、まず次のことを認識する必要があ

ります。クラスが自分の仕事（ある種のアグリゲートの管理）

を行うだけでなく、さらなる責務（反復処理など）を行えるよ

うにすると、そのクラスを変更する理由を

2

つ与えることにな

ります。

2

つ？

そう、

2

つです。コレクションが何らかの方法

で変更された場合と、反復処理の方法が変更された場合に、そ

のクラスが変更される可能性があります。そこで、再び「変更」

が別の設計原則の中核となります。

 クラス内の変更は避けたいものです。コードの修正は、問題

が忍び込むさまざまな機会を与えることになります。変更する

理由が

2

つあると、クラスが将来変更される可能性が高くなり、

変更があった場合は設計の

2

つの側面に影響を与えることにな

ります。

 解決策はあるでしょうか？

この原則は、責務は

1

つのクラス

に

1

つだけ割り当てるように指導しています。

 これは正しいことです。簡単そうに見えますが、実際は簡単

ではありません。設計の際に責務を分離することは最も難しい

ことの

1

つです。私たちの頭は、実際に

2

つ以上の責務があっ

ても、一連の振る舞いをグループ化することがとても得意なの

です。うまくやるには、設計の検証を熱心に行い ...