機能分解 - memomem @ ウィキ

オブジェクト指向以前は、いわゆる「構造化プログラミング」時代と呼ばれ、機能分解（functional decomposition）の手法がとられていました。問題を小さな機能にブレークダウンしていき、複雑さを回避しようとするアプローチです。図にするとピラミッドストラクチャのようになります。ブレークダウンされるごとに凝集度は高まり、見通しも良くなるので自然と複雑度は下がります。

だけど、ここには落とし穴がありました。このアプローチでは、結果的に「メイン」モジュールが必要となります。機能の組合わせとその呼び出し順を正しく制御する、大きな責任を持ったモジュールです。こういった構造になっていると、モジュールの変更が制御できなくなります。「他の関数」「データ」「やり取り」「順番」等、注意を払うべき項目が多すぎるからです。

機能やデータを変更すると、他の機能や他のデータに影響が及び、それがまた他の機能に影響を及ぼすという修正の連鎖が「芋蔓式」に発生し、「将棋倒し」が起こります。その中でも特に影響が大きいのが「データ」の変更についてで、データが機能に従属して拡散してしまっているため（方々で使っているだけでなく、引数による上下渡り歩きも含む）、影響範囲の見極めが非常に困難になります。

好ましくない副作用

この時代、多くのバグが、変更によって生み出されていました。変更による不具合のことを「好ましくない副作用」といいます。機能に注力することは、発見しにくい副作用を生み出す近道になってしまうのです。そして保守作業とデバッグ作業にかかる時間の大半は、バグの除去に充てられる時間ではなく、バグの発見、および修正によって生み出された好ましくない副作用の回避手段を考え出す時間に充てられていました。

つまり、ソフトウェアライフサイクルに必ずある変更において、例えばバグ修正時であれば二次バグ、機能追加時であればデグレードの発生など、常に危険に晒されている手法だということです。そして、本来使うべき開発そのものの時間ではなく、この副作用の収束に多くの時間を取られるという形で問題が顕在化したのです。
オブジェクト指向へ

変更は必ず発生するものです。ただ、そのことが直ちに負けを意味している訳ではありません。どう変わるかはわかりませんが、どこが変わりそうかはある程度予想できるのです。

参考>開発手法の目的

オブジェクト指向とは