ハイブリッドOOPLの呪い

OOP

手続きプログラミングとオブジェクト指向プログラミングはなんだかどうも癒着してしまって、別のプログラミングパラダイムという気がしてこないのが、実は諸悪の根源なのではないかと思ってしまいます。

C++ なんかでは、OOPLになったといっても手続きを流し込む大箱が追加されただけで、メンバ関数の中に降りていけば、そこに見慣れた手続きプログラミングが広がっています。Smalltalk なんかですと、メソッドの中の小コードであってもこれはもう手続きではなくって、メッセージ式が連なっていく様はむしろ関数言語に似ています。

「純粋OOPL」「ハイブリッドOOPL」の違いは、「全てがオブジェクトであるか」とか「最初からOOPLとしてスクラッチビルドされたか、既存言語を増築したか」ではなく、実はこの差なのでは、と思います。sumimさんが啓蒙されているような「二つのOOP」があんまりフツーには知られていなかった頃、その「OOP」の差をなんとか表現しようとしてチョットずれちゃった・・・みたいな、そんなかんじかな、と妄想しています。

その妄想にしたがって用語を拝借しちゃいます。「純粋OOPL」側だと、クラスを作らなかろうが数行しかないコードであろうが それはOOPで、OOPの恩恵を受けるのだけれど（だからオブジェクト指向スクリプティング言語が欲しくなる）、「ハイブリッドOOPL」の方は、そう言うコードは単なる手続きプログラミングでしかないので、OOPは大規模じゃないと役に立たない（むしろ小規模プログラミングを解りにくくする）なんて言われてしまう。

「純粋」側はプログラムを責務分散協調系に形作るという思想が何時でもどこでもなので、頭をスイッチする必要がなくって楽に感じます。と、そういうわたしは「純粋」側な Smalltalk が好きなのでこれは贔屓。どちらが、と言うことでもないのでしょう（と無難なところに落とし込んでおこう）。

なんだか前置きが凄く長くなってしまいましたが、ようやく言いたいこと。ハイブリッドだからって、ifとelseの思考術だけで通用すると思うなっ！・・ということです。

いっそのこと、ハイブリッドなんてなければ「もっと OOP って全然 俺らの知ってる『プログラム』と違うじゃん。やっべー、、、」となるのに。ハイブリッドなOOPL は OOP に掛けられた呪いなのかもしれない。