オブジェクト指向プログラミングに特に熱心でないARCの理由

2001年1月

オブジェクト指向プログラミングに対する熱狂が今のところ存在しますが、私の知る最も賢明なプログラマの一部は、それほど熱心ではありません。

私の考えでは、オブジェクト指向プログラミングは特定のケースでは有用な手法ですが、書くプログラムすべてに浸透する必要はありません。新しい型を定義することはできますが、すべてのプログラムを新しい型の定義として表現する必要はありません。

オブジェクト指向プログラミングが人気な理由は5つあると思いますが、そのうち3つと半分は良くない理由です:

静的型付き言語で、レキシカルクロージャーやマクロがない場合、オブジェクト指向プログラミングは刺激的です。ある程度、これらの制限を回避する方法を提供します。(「グリーンスパンの第10の法則」を参照してください)

オブジェクト指向プログラミングは大企業で人気があります。それは、彼らがソフトウェアを書く方法に合っているためです。大企業では、ソフトウェアは中程度のプログラマの大きな(そして頻繁に変わる)チームによって書かれる傾向があります。オブジェクト指向プログラミングは、これらのプログラマに規律を課し、個人による大きな被害を防ぎます。その代償は、結果として得られるコードがプロトコルで肥大化し、重複が多くなることです。大企業にとっては、ソフトウェアがそもそも肥大化し、重複が多いのであれば、それほど高い代償ではありません。

オブジェクト指向プログラミングは、多くの作業をしているように見えるものを生み出します。かつてのファンフォールドの時代には、ページ上わずか5行から10行のコードしか書かない一方で、丁寧にフォーマットされた20行もの解説コメントを書くプログラマがいました。オブジェクト指向プログラミングはこれらの人々にとって麻薬のようなものです。ソースコード内に足場組みを組み込むことができるのです。Lispハッカーが記号をリストに押し込むようなことが、クラスやメソッドのファイル全体になってしまうのです。したがって、自分や他人に多くの作業をしているように見せたい場合には、良いツールとなります。

言語自体がオブジェクト指向プログラムであれば、ユーザーが拡張できます。まあ、そうかもしれません。あるいは、オブジェクト指向プログラミングのサブコンセプトをアラカルトで提供する方が、さらに良いかもしれません。たとえばオーバーロードは、クラスと本質的に結びついているわけではありません。これからどうなるかわかりません。

オブジェクト指向の抽象化は、シミュレーションやCADシステムなどの特定のドメインのプログラムにうまくマッピングされます。

私個人は、オブジェクト指向の抽象化を必要としたことがありません。Common Lispには強力なオブジェクトシステムがありますが、私はそれを一度も使ったことがありません。(ハッシュテーブルに閉じ込めるなど)弱い言語ではオブジェクト指向の手法が必要となるような多くのことをしてきましたが、CLOSを使う必要はありませんでした。

私が単に愚かで、プログラミングの範囲が限られているのかもしれません。自身の経験に基づいて言語を設計するのは危険です。しかし、使ったことがないのに良いアイデアだからといって、機能を追加するのはさらに危険だと思います。