オブジェクト指向プログラミングとは何か
プログラムとはそもそも何か。*1
プログラムとは、何らかの方法で保管されたデータを、何らかの方法で操作・加工することである。
a→b→c→...→x
入力したaというデータを加工していって、最終的にxというデータを得る。aからxを得るのがプログラムの目的である。*2
オブジェクト指向プログラミング（OOP）以前のプログラマは、二つの指揮を同時に行なっていた：
- データ加工i→jが具体的にどんなプロセスで行われるべきか
- aからxに到るまでのデータ加工の工程がどうあるべきか
厄介なのは１と２は相互作用していることだ。データ構造や加工の方法を変更すると、それが工程にも影響を与えるし、逆もまた然りである。
二つの変数があると問題は難しくなる。そこでよく採られる常套手段は、どちらか一方を固定するというものである。それがOOPのアイデアに他ならない。
OOP以後のプログラマは、二つの指揮を個別に行えばよくなった：
- オブジェクトの中身の設計
- オブジェクト間の情報の流れの制御
要はプログラムをオブジェクトの内と外に分けて、困難を分割したのである。このオブジェクトの内と外に分けるというのが、カプセル化という概念が表している意味である。
２の作業、つまりデータの流れ (stream) の制御を行なっているとき、プログラマは1について知る必要がない。知るべきなのは単にiというデータがjに加工されるという事実のみである。具体的にどうやってi→jが実現されるのかは（２の作業中は）どうでもよい。このことを指して、オブジェクトはブラックボックスなどと言われたりもする。つまりオブジェクトがブラックボックになって、中身が見えなくなってしまっても一向に構わないということだ。
オブジェクトがカプセル化され、中身が見えなくなったことによって、プログラマは２の作業に専念出来る。また、他人が作ったオブジェクトの中身をわざわざ理解しなくても、「iを入れたらjが出る」という情報（これをインターフェースと呼ぶ*3）が分かってさえいればそれが使える。こうしてプログラムの再利用も容易になる。
また逆に１の作業中は２を気にする必要はない。オブジェクトが持つべきインターフェース（＝iを入れたらjが出る）さえ実現すれば、どんな設計をしても良い。*4*5
これらの利点はすべてコードをオブジェクトの内と外に分けるというカプセル化の概念から出てきた。したがって次が言える：
オブジェクト指向プログラミングの本質はカプセル化にある。*6
OOPは上で述べたようなものだが、そこではクラスベースとか継承や多様性といった概念は登場してこなかった。なぜならクラスベースや継承や多様性といった概念はOOPの本質ではないからである。それは単にOOPをより効率的に実現するためのテクニックでしかない。しかしそれはあまりに便利であるから、OOPを行うときには必ずといって良いほど紹介される。だが、何度も繰り返すがそれはOOPの本質ではない。
最後に
残念ながらOOPの本質を理解しても、OOPが出来るようになるわけではない。OOPを実際に行うためには、用いる言語でOOPを行うための仕様を理解し、それを覚えて使えるようにしなければならない。それにクラスベースや継承、多様性といった概念も身につける必要がある。そのためには練習 (practice)あるのみだ。ただ練習する上でOOPのアイデアを理解しておくのはとても有用であるのは間違いない。
*1:以下では特定の言語に依らない説明を心がける。言語を決めてしまうと、その言語仕様に気が取られたり、そもそもその言語を知らないといったことが足かせになってしまう。オブジェクト指向プログラミング (OOP) はプログラム記述方法のアイデアであり、その記述方法で具体的にプログラムを書くときにやっと言語が問題になってくる。OOPの本質的アイデア自体は特定の言語を設定しなくても語れるし、そうするべきだとも思う。
*2:もちろん実際のプログラムはこのような単純な一本道とは限らない。入力がたくさんあったり、道が分岐したり、ループしたりするだろう。ただ一本道としても議論の本質は失われない。
*3:元々インターフェースというのは外界とのやりとりを司る部分という意味である。別の言い方をすれば「上っ面」だ。OOPでは物事の上っ面だけみればよいから楽なのだ。
*4:もちろん効率の良い設計が望ましいだろうが。
*5:ただもちろんその肝心のインターフェースがどんなものか知るためには、２についての理解が必要にはなるだろう。しかしそれでも１が２に影響することはない。これが肝心であり、カプセル化の利点である。
