Cogito Ergo Sum.

我思う故に我あり

そうか、部品化するのは、処理じゃなくてデータだ。

 「オブジェクト指向プログラミング」のキーワードの1つに、「プログラムの部品化・再利用」というものがある。「『オブジェクト』は再利用可能なプログラム部品だから、オブジェクトを中心に据えてプログラムをつくる『オブジェクト指向プログラミング』によって、プログラム開発の効率が良くなる」というわけだ。

 文字通りの意味でならこの文章を理解できるにも関わらず、「そもそも、どうしてオブジェクトを中心に据えると、プログラム開発の効率が良くなるのか」が長い間僕には理解できなかった。それは、「再利用可能なプログラム部品」として僕が、「関数のようなもの」つまり「処理」を思い浮かべていたからだろう。

 「関数を中心に据えてプログラムを作る」というのはC言語のコンセプトそのものなので、「オブジェクト指向プログラミング」が「構造化プログラミング」に付け足したものが何なのか、僕には理解できなかった。僕は「オブジェクト」を「関数に専用のデータを持たせたようなもの」と理解していたのだが、それじゃただの「関数」に過ぎないので、内部を隠蔽するだの、スーパークラスを継承するだの、といった「仕掛け」を使うのが「オブジェクト指向プログラミング」なんだと思っていた。で、それによっていったい何がもたらされたのかサッパリ理解できなかった。

 考えてみれば、オブジェクト指向プログラミングによってもたらされたのは「関数の部品化」ではなく「データの部品化」だ。データとそのデータ自身を対象とする処理を一まとめにして「オブジェクト」とし、そのオブジェクト自身に仕事(自分自身に対する処理)をさせようというのがオブジェクト指向プログラミングなのだから。そう考えてみれば、入門書で「社員クラス」なんてものを定義したりするのもよくわかる。部品化されるのは、社員データに対する「処理」ではなくて、「社員データ」の雛形そのものだ。

 オブジェクトを「構造体に(自分自身を対象とする)処理をもたせたようなもの」と考えれば、人目にさらす必要のない処理を隠してしまったり、似たようなオブジェクト間に汎化・継承関係を設定したり、直接似てはいなくてもある観点から見たときに似ているものには普遍的なインタフェースを実装したりする…、というのは至極当然の発想だと思う。似たようなデータには似たような処理を施すことになるのだから、それは概念的なスーパークラスに記述しておいて、個々のクラスでは個別事情についてだけ記述する、というのは合理的だ。

 僕が何故「オブジェクトとは構造体に処理をもたせたようなもの」という発想が出来なかったかと言えば、僕の書くプログラムでは構造体というものを一切使わないからだろう(僕は構造体だけでなく、列挙体もポインタも一切使わない)。僕はやっぱりC言語文化みたいなものからずっと距離をおいてきた人間なんだなぁと思う。