ARC が特にオブジェクト指向ではない理由

2001年1月

現在、オブジェクト指向プログラミングに対する一種の熱狂が広がっていますが、私が知る最も優秀なプログラマーの中には、オブジェクト指向プログラミングにあまり興味がない人もいます。

私自身の考えでは、オブジェクト指向プログラミングは場合によっては便利なテクニックですが、書くすべてのプログラムに浸透させる必要はありません。新しい型を定義できる必要がありますが、すべてのプログラムを新しい型の定義として表現する必要はありません。

人々がオブジェクト指向プログラミングを好む理由は 5 つあると思いますが、そのうち 3 つ半は悪い理由です。

オブジェクト指向プログラミングは、語彙クロージャやマクロのない静的型付け言語を使用する場合に魅力的です。ある程度、これらの制限を回避する方法を提供します。(グリーンスパンの第 10 ルールを参照してください。)

オブジェクト指向プログラミングは大企業で人気があります。なぜなら、それが彼らのソフトウェアの書き方に合っているからです。大企業では、ソフトウェアは、大勢の (そして頻繁に入れ替わる) 凡庸なプログラマーのチームによって書かれる傾向があります。オブジェクト指向プログラミングは、これらのプログラマーに規律を課し、プログラマーの 1 人が大きな損害を与えるのを防ぎます。その代償として、結果として得られるコードはプロトコルで肥大化し、重複だらけになります。大企業にとって、これはそれほど高い代償ではありません。なぜなら、彼らのソフトウェアはいずれにしても肥大化し、重複だらけになる可能性が高いからです。

オブジェクト指向プログラミングは、作業のように見えるものを大量に生成します。ファンフォールドの時代には、ページに 5 行か 10 行のコードと、その前に 20 行の入念にフォーマットされたコメントを記述するだけのプログラマーがいました。オブジェクト指向プログラミングは、こうした人々にとって麻薬のようなものです。オブジェクト指向プログラミングでは、こうしたすべての足場をソース コードに直接組み込むことができます。Lisp ハッカーがシンボルをリストにプッシュすることで処理できるものが、クラスとメソッドのファイル全体になります。そのため、自分自身や他の人を、自分が多くの作業を行っていると納得させたい場合、これは優れたツールです。

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

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

個人的には、オブジェクト指向の抽象化が必要になったことはありません。Common Lisp には非常に強力なオブジェクト システムがありますが、私は一度も使用したことはありません。より弱い言語ではオブジェクト指向のテクニックが必要となるようなこと (たとえば、クロージャでいっぱいのハッシュ テーブルの作成) をたくさん行いました。しかし、CLOS を使用する必要は一度もありませんでした。

たぶん私はただ愚かなだけか、あるいは限られたアプリケーションの一部にしか取り組んでいないのでしょう。自分のプログラミング経験に基づいて言語を設計するのは危険です。しかし、良いアイデアだと思ったからといって、必要のないものを組み込むのはもっと危険に思えます。