オブジェクト指向は構造化手法を前提として拡張した設計思想である
オブジェクト指向は、構造化手法を否定するものではなく、その考え方を前提として拡張した設計思想です。
構造化手法が「正しく動くプログラム」を目指すものであったのに対し、
オブジェクト指向は「柔軟で再利用しやすい設計」を目指しています。
つまり、構造化の基盤の上に、より高い抽象化レイヤーを築いたものがオブジェクト指向なのです。
構造化手法とは何か
構造化手法（Structured Programming）は、複雑なプログラムを整理して理解しやすくするための技法です。
次の4つの基本構造によって、処理の流れを明確にします。
-
シーケンス：処理を順番に実行する構造
-
制御構文：条件による分岐を表す構造
-
反復構文：繰り返し処理を記述する構造
-
機能分解：処理を階層的に分割し、木構造で整理する手法
これらによってプログラムは「上から下へ」「大から小へ」と整理され、論理的に明確になります。
構造化手法は、ソフトウェア設計をするにあたって必須な基礎知識です。
オブジェクト指向は構造化手法の自然な発展形
オブジェクト指向もまた、この構造化の文法を前提にしています。
したがって、「オブジェクト指向は構造化手法を包含している」と言って差し支えありません。
ただし、両者の焦点は異なります。
構造化手法が「どのように動くか（制御構造）」に注目していたのに対し、
オブジェクト指向は「誰が何を責任として持つか（責務）」を中心に据えています。
これにより、クラスとインスタンス、カプセル化、継承、多態性といった新しい概念が導入されました。
ソフトウェアは単なる命令の集まりではなく、現実世界の概念や役割を反映したオブジェクトの協調として設計できるようになったのです。
可視化の進化：DFDからUMLへ
設計を「見える化」する手法にも、この変化が表れています。
構造化手法での可視化
-
データフロー図（DFD）：データの流れと処理の関係を示す
-
構造図（階層構造図）：機能分解を階層的に表す
-
状態遷移図：状態変化と遷移条件を明示する
これらは、システム全体の処理の流れや依存関係を理解するのに非常に有効です。
オブジェクト指向での可視化
オブジェクト指向では、UML（統一モデリング言語）を使って設計を可視化します。
-
クラス図：オブジェクト間の関係を表す
-
シーケンス図：メッセージのやり取りを時系列で示す
-
ユースケース図：ユーザーとシステムの関係を抽象化する
-
アクティビティ図：業務や処理の流れを表現する
構造化手法が「処理の流れ」を描くのに対し、
オブジェクト指向のUMLは「関係と責務の構造」を描きます。
可視化の目的は同じでも、焦点が異なるのです。
デザインパターン：オブジェクト指向の知見を体系化したもの
オブジェクト指向設計では、似たような構造や問題が繰り返し現れます。
これらを整理して共通の設計知識としてまとめたのがデザインパターンです。
1990年代、GoF（Gang of Four） が著書
『Design Patterns: Elements of Reusable Object-Oriented Software』
で、頻出する設計構造を23種類のパターンとして体系化しました。
デザインパターンは、オブジェクト指向設計で繰り返し現れる問題とその解決を体系化し、名称づけによって共通言語として共有可能にしたものです。1990年代に GoF（Gang of Four） が『Design Patterns: Elements of Reusable Object-Oriented Software』としてまとめたことで、設計レビューやドキュメントで意図を短く正確に伝えやすくなり、実務での合意形成や再利用の促進に大きく寄与しました。
結論：構造化の上に成り立つオブジェクト指向こそが現代の設計基盤
構造化手法を理解せずにオブジェクト指向を学ぶのは、文法を知らずに文章を書くようなものです。
しかし、構造化を意識的に併用する必要はありません。
オブジェクト指向そのものが、構造化の原則を内包し、さらに発展させた設計手法だからです。
オブジェクト指向を正しく理解し実践することが、
結果的に構造化手法の理念をも包含し、より良い設計につながります。
時代が変わっても、「良い設計の本質」は変わりません。
構造化の上に成り立つオブジェクト指向こそ、今なお通用する普遍的な設計思想なのです。
こちらも参考にどうぞ。