（1） 構造的 プログラミング
　（2） 抽象 データ 型

　複数の ファイル を読み込んで、レポート などの アウトプット を手続き型言語を使って作成する際、構造的 プログラミング が多く用いられてきました。

　構造的 プログラミング は、ソリューション を第一義に考えて、ソリューション を手続き的に変換して、変数のなかに値を代入し、1つずつの ステップ を実行する やりかた です。1つずつの ステップ を実行する際、「場合分け」 を網羅して、コントロール・フロー は、「判断 （IF） と繰返し （ループ 制御）」 の操作を基本としています。「データ の型 （構造化）」 は、問題に即応した型が定義されます。

　いっぽう、抽象 データ 型は、データ に固有な操作も同時に扱い、データ とプロセス を カプセル 化する やりかた です。オブジェクト とは、対象とする事態にふくまれている 「モノ」 のことです。この オブジェクト に関して、「型」 を考えるかどうかは、争点の １つになるでしょうね。共通の性質をもつ オブジェクト を代表した クラス を考えることができます。さらに、「クラス の クラス」 を考えることもできます。したがって、クラス の階ができます。この構成のなかで、クラス の性質は、「継承」 されます。

　
　さて、私は、データベース・パラダイム で仕事をしている エンジニア で、TM （Ｔ字形 ER手法） を使って データ 設計を本職にしています。そして、ほかの人たちが作成した クラス 図を、ときたま、観ることがあるのですが、それらの図が、どうも、「階層構造型 データベース」 向けの設計図に近いので、唖然としています--すなわち、オブジェクト 指向だと言いながら、オブジェクト 指向になっていない。そういう図を クラス 図だと言われても、私は、かれらが オブジェクト 指向を理解していないとしか思えない。

　かれらが、どうして、そういう事態に陥っているのかを推測してみると、かれらは、まず、ソリューション を 「捻出して」、ソリューション に適合できる データ の型を考えているようです。すなわち、まず、「設計図ありき」 という態度を かれらは とっているようです。こういう態度は、まるで、「put the cart before the horse （馬の前に荷台を置く）」 ような本末転倒な態度でしょうね。というのは、「事実を 『正確に』 記述」 しなければ、事態のなかの問題点を感知することができないし、問題点を感知できないなら、ソリューション も出ないから。本来の やりかた は、「事実」 を記述するために、オブジェクト を認知して、クラス を構成するはずです。

　ソフトウェアハウス の プログラマ たちが、SQL を使って構造的 プログラミング をやって奇怪な プログラム を作成している事態を、私は、多々、観てきたのですが、同様に、オブジェクト 指向と言いながら、構造的 プログラミング に似た やりかた をしているのを、多々、観ます。どうして、こういう混乱が起こっているのかしら、、、。

　
　（2007年 9月23日）