脱オブジェクト指向の理由・なぜオブジェクト指向を脱する必要があるのか?

　最近、「脱オブジェクト指向」という言葉を書いていますが。

　なぜオブジェクト指向を脱する必要があるのか、ということについて書いておきます。

　まず、今、私が試みているプログラミングスタイルは、今のところ仮に「手順的」称しています (これが正しいやり方かどうかは分かりません。念のため)。手順的プログラミングは、脱オブジェクト指向と認識しています。

　手順的プログラミングは、「プログラムとは、時間順に実行される命令の列であるので、処理の流れ、手順が分かりやすいことが重要である」という考え方に沿ったものです。たとえば、あるメソッド呼び出しが実際に呼び出すメソッドがどれか分かりにくく、限定することができないという点で、継承に対して否定的な立場を取ります。

　さて、実際に継承に対して否定的な態度というのは、オブジェクト指向の世界にもあるようです。そういう意味で、継承しないプログラミングは、オブジェクト指向を脱しているとは言えない、という考え方も可能です。

　実際、私自身、エクストリーム・プログラミングのメーリングリストで、大ホラ的に「オブジェクト指向の縁」という言葉を書いてみたことがあります。これは、「オブジェクト指向の軽視」のより適切な言い換えであり、適応型ソフトウェア開発という書籍で取り上げられている「カオスの縁」からヒントを得た言葉です。オブジェクト指向は完成された秩序であるがゆえに適応性を欠いているため、適応性を得るためにはオブジェクト指向と他の方法論の特徴が混在する「オブジェクト指向の縁」に移動する必要がある、というような話です。この文書は、適応型ソフトウェア開発について書く場でもなければ、「オブジェクト指向の縁」について論じる場でもないので、このぐらいで終わりにしますが、明らかに、手順的プログラミングは、ここでいうオブジェクト指向の縁の領域にあると見なせるものです。

　それにも関わらず、なぜ、脱オブジェクト指向と称するのか。

　その理由は、より根元的な考え方の部分にあります。

　この考え方の起点は、XMLにあります。xml-usersメーリングリストで何年も前に、XMLはオブジェクト指向ではないし、要素はクラスではない、というような話が出ています。その点で、XMLは脱オブジェクト指向的であると言えます。しかし、更にその先の話があります。XMLの世界では、新しい言語を設計して、それからそれを利用する不特定多数の応用プログラムが作成されるような形態が多く見られます。データとプログラムのどちらを主と見るかという視点で見れば、これはデータ中心主義と言えます。まずデータがあり、それからプログラムが作成され、しかもプログラムは1つに限られません。プログラムごとにデータの解釈が違うということもあり得ます。(XML界でいうボヘミアン的な解釈)

　これに対して、オブジェクト指向は、1つのクラスという入れ物に、データとそれを処理するプログラムが含まれる形を取ります。これは、データとプログラムを同格の存在として扱うものであるように思われます。また、データを解釈するプログラムが必ずワンセットで組み込まれるため、プログラムによって解釈が変わるということもありません。厳密にどうかは知りませんが、こういう風に私には見えています。

　ということは、このことから時代の流れをまとめると、かつての圧倒的なプログラム中心主義(データはプログラムが作成するオマケ的な存在)から、1990年代のオブジェクト指向ブームにより、プログラムとデータを同格とする時代に進化し、そして、その次に来たのは1998年誕生のXMLがもたらしたデータ中心主義だと言えるかもしれません。このような流れから見れば、クラスという殻の中でデータがプログラムに拘束されてしまうオブジェクト指向的な考え方は、XML時代には窮屈であると感じられます。データは完全にプログラムから解放されて自由になるべきです。

　そのようなデータの完全解放という気持ちを込める意味で、オブジェクト指向は脱すべき対象である、というようなことを考えてみましたが、本当は後からこじつけた理屈です (笑い)。

　データをプログラムから独立した存在と見なすと、プログラムのモデルはオブジェクト指向と変わります。オブジェクト指向のプログラムは処理すべきデータを自分自身の中に持ち、オブジェクト間が相互作用することで処理が進みます。しかし、データはプログラム外にある自由な他者であるとするならば、プログラムのモデルは、「入力→処理→出力」という流れが基本となります。(これは、サーバサイドのWebアプリケーションの構造とも一致します。「リクエストを受け取る→処理→結果を返送」と同様の流れになります)

　ちなみに、手順的プログラミングで、プログラムが処理される流れを重視して、データについて特に言及がないのは、データは外部からやってくる他者であると考えるためです。プログラムの都合でデータの構造を決められない以上、データのあるべき姿についてのビジョンは含まれません。

　このような状況でクラスが担う役割は、処理すべき対象の本質をモデル化したものではなく、処理を適切に実現するためのカプセル化機能を提供するための存在ということになります。つまり、クラスは処理の都合で生まれるべきものであって、そこに現実世界の何かに対応する立場のようなものは求められません (オブジェクト指向でいう自然な役割分担を要求されない)。ここで必要とされるのは、複雑さを軽減するための手段としてのカプセル化と、それを実現するための機構としてのクラスです。

　複雑さの軽減については、10年以上考えていたことなので、そのうちにその話題も書きましょう。

　それはさておき、そのように考えると、ここで明確に排除されているのは、オブジェクト指向的なプログラミングというよりも、オブジェクト指向的なモデリングであると言えるかもしれません。

　いずれにせよ、脱オブジェクト指向が正しいことかどうか、手順的なプログラミングが正しいことかどうか、そのことはまだ分かりません。これはアイデアを探索する試みですから、けして、オブジェクト指向の正しさを懇々と説教しようなどと思わないように (笑)。