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

January 2001

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

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

オブジェクト指向プログラミングが人々に好まれる理由は5つあると思いますが、そのうち3つ半は良くありません。

レキシカルクロージャやマクロのない静的に型付けされた言語を持っている場合、オブジェクト指向プログラミングはエキサイティングです。ある程度まで、それはこれらの制限を回避する方法を提供します。（グリーンスタインの第10法則を参照してください。）

オブジェクト指向プログラミングは大企業で人気があります。なぜなら、それは彼らがソフトウェアを書く方法に適しているからです。大企業では、ソフトウェアは、大規模で（頻繁に変化する）中程度のプログラマーのチームによって書かれる傾向があります。オブジェクト指向プログラミングは、これらのプログラマーに規律を課し、1人のプログラマーが過度の損害を与えるのを防ぎます。その代償として、結果として得られるコードは、プロトコルで膨らみ、重複だらけになります。これは、大企業にとってはそれほど高い代償ではありません。なぜなら、彼らのソフトウェアは、いずれにせよ膨らんでいて、重複だらけになる可能性が高いからです。

オブジェクト指向プログラミングは、一見多くの作業を生み出します。ファンフォールドの時代には、1ページに5行から10行のコードしか書かず、その前に20行の精巧にフォーマットされたコメントを付けるタイプのプログラマーがいました。オブジェクト指向プログラミングは、これらのプログラマーにとってクラックのようなものです。それは、この足場をすべてソースコードに組み込むことができます。Lisp ハッカーがリストにシンボルをプッシュすることによって処理するようなことが、クラスとメソッドの完全なファイルになります。そのため、自分自身または他の人を説得したい場合、これは良いツールです。

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

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

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

たぶん私はただ愚か者か、アプリケーションの限られたサブセットに取り組んできたのかもしれません。自分のプログラミング経験に基づいて言語を設計することには危険があります。しかし、必要としたことがないものを、良いアイデアだと思われているからといって、そこに置くことは、さらに危険なように思えます。