Javaの登場によってオブジェクト指向(以下OOP)は一気に普及しました。 そのJavaもリリースが1996年と、もはや干支も廻るぐらいの時が経ち、OOPを扱える技術者も増えました。 身近なところでもOOPを使える人が見つかる可能性は高くなりましたし、学習がより行いやすい環境になってきていると思います。

それでもOOPを解するための壁は厚いと言わざるを得ません。 静的オブジェクト指向は設計者が苦労を背負込むシステム の稿では

Javaの静的オブジェクト指向というのは、クラスを設計する側の立場に立つと非常に苦労するものなのですが、クラスを使う側には非常に楽なものなのです。 Java界隈で仕事をする会社の新人教育は、この「クラスを使うことができる」レベルまで到達出ていればよいとされていると言って過言ではないでしょう。

と、OOPで設計されたクラスの「使い手」と「作り手」に求められる技術力の壁を指摘し、まずは「使い手」レベルまで到達する必要があることを述べました。

ソースコードを追いかけにくい理由

OOPの壁はなんといってもポリモフィズム(多態)ではないでしょうか。

ポリモフィズムによって、実行時に動的に処理のフローチャートが切り替わるのです。

この動的フローは 構造化定理で挙げられる「順次・反復・分岐」の3つの基本的な論理構造と、 それを基に構造化プログラミングで提唱された「サブルーチン」という古典的な処理フローとは異なるパラダイムです。

そして、このパラダイムは 高階関数(関数を引数や戻り値とする関数)などを用いる場合には理解していなければならなず、 既存の言語でそれを得てきているのであれば、ポリモフィズムを理解するための基礎的な道具は揃っており、 OOPへの移行はそれほど大きな壁とはならないことでしょう。

具体的には、C言語でも関数ポインタを自在に操れる人であれば、 実行時に動的にフローチャートが切り替わることを利用した アルゴリズムを組んだり設計をしたりすることが出来ることでしょう。 この関数ポインタによる動的な処理フローこそが、OOPを解するための一番の壁ではないかと私は睨んでいるのです。

OOPのコードが追いにくいのは動的なフローであるからです。 そしてそれは契約に基づくプログラミングでは「結果を返してくれる何か」と抽象化して委譲するので そこより先のフローに立ち入りません。

つまり、デバッグ時以外ではこの動的フローを強く意識せずともプログラムは書けるわけで、 動的フローが身についていないままデバッグの段で動的フローに触れることになると、 「OOPは役に立たない。コードの可読性を損なうだけで百害あって一利なしだ！」 と憤慨することになりかねないのです。

オブジェクト指向の学習のお膳立て

OOPを解するためのお膳立てとして、以下のようなものを揃える必要があると思います。

• 構造化定理における「順次・反復・分岐」
• 構造化プログラミングにおける「サブルーチン」
• C言語の構造体などの、階層化したデータ構造
• 関数ポインタ、高階関数に見られる動的な処理フロー

これらの材料がそろっているのであれば、OOPを理解するまではさほど時間はかかりません。型システムを理解し 契約プログラミング(programming by contract. 契約に基づくプログラミング、などとも呼ばれる。) を抑え、OOPを形作るのにいくらかの実習を行えば済むことでしょう。