「仕様変更の影響を局所化する」ことが良い設計

ここでの仕様変更とは、仕様追加も含むこととします。そうすると、アジャイルだとかウォーターフォールだとかに関係なく、開発のかなりの部分は仕様変更による対応で占められることになります。仕様変更に対し、いかに容易に対応するのかがポイントになってくるわけです。
平鍋さんのEoM = EoT + EoCシリーズもぜひお読みください。
http://blogs.itmedia.co.jp/hiranabe/2005/08/post_e66c.html
http://blogs.itmedia.co.jp/hiranabe/2005/08/_eocease_of_cha_602c.html
http://blogs.itmedia.co.jp/hiranabe/2005/08/eom__ease_of_ma_8db3.html
歴史的な流れで言うと、グローバル変数などを多用したCOBOLでの開発では、仕様変更が起きたときに、影響範囲が思いのほか大きくなってしまうという問題点がありました。昔は、比較的開発期間を長く取ることができたので、それでも何とか対応できていたのですが、開発期間の短縮が叫ばれるようになるとそれでは対応ができなくなってきたのです。
そこで仕様変更が起きたときでも、その影響範囲をできるだけ局所化する技術として登場したのが、OOPの言語です。
関連するデータと振る舞いをカプセル化するという考えも、まさに「仕様変更の影響を局所化する」ことから生まれたものです(と思う)。「仕様変更の影響を局所化する」という目的を達成するための手段として、「関連するデータと振る舞いをカプセル化する」方法があるわけです。最近(結構昔から)は、「関連するデータと振る舞いをカプセル化する」という本来は手段だったことが目的になってしまっている人がいるみたいで、残念に思うこともあります。
それでは、「仕様変更の影響を局所化する」にはどうすれば良いのでしょうか。
それには、クラスの凝集度を上げ、クラス間の結合度を下げることが重要です。
赤坂さんの「設計におけるオブジェクトの責務分配に有効なものさし」もぜひお読みください。
http://www.ogis-ri.co.jp/otc/hiroba/technical/Cohesion_Coupling/Cohesion_Coupling.html
凝集度を上げるためには、関連する機能を1つにまとめることが重要です。逆に関連の無い機能をいっしょにした場合、凝集度は下がることになります。関連する機能が1つにまとまっていると仕様変更があった場合に、その特定のクラスだけを修正すればよくなるので、影響を局所化できます。
結合度を下げるためには、お互いに相手のことをできるだけ知らなくても良いようにします。インターフェースで会話をするようにすると結合度を下げることができます。実装クラス同士がお互いに知り合いなのは、できるだけ避けるべきです。1つの実装クラスの変更が変更の連鎖を引き起こす場合があるためです。変更が連鎖しなければ、影響を局所化できます。
クラスの凝集度を上げ、クラス間の結合度を下げることがOOの重要なポイントだといえます。