Erlangの人気が高まると、彼らはしばしば「Erlangはオブジェクト指向ですか？」という質問をし始めました。 正解は「-あなたは何ですか、いや！」です。 しかし、私たちはフルボイスでそう言うことができなかったので、外に出なければなりませんでした。 Erlangを型オブジェクト指向言語（この質問に手を差し伸べる可能性が最も高い人向け）として表すだけでなく、実際にサブジェクト内にいる人向けにはオブジェクト指向型ではない、いくつかのかなり重要な答えを思い付きました。
ここで、論理プログラミングに関する第7回IEEE会議でフランスIBMのディレクターの論文を思い出したいと思います。 彼は、IBMが多くのオブジェクト指向拡張をPrologに追加したと言いました。 この理由について尋ねられたとき、彼は答えた：
「-顧客はオブジェクト指向のプロローグを望んでいたので、オブジェクト指向のプロローグを作成しました」
覚えている、私は思った。 それは簡単で、後悔も、内省も、正しいことをやり直すこともありません。」
オブジェクト指向プログラミングがひどい理由
OOPの主題に対する私の個人的な異議は、その主な条項に対する主張です。 これらの規定のいくつかと私の主張の本質を強調します。
異議第1 データ構造と機能は互いに結び付けてはいけません。
オブジェクトは、関数とデータ構造を不可分なエンティティにまとめます。 関数とデータ構造はまったく異なるカテゴリに属する概念であるため、これは根本的な間違いだと思います。 これはなぜですか？
関数はアクションを実行するためです。 入力値と出力値があります。 入力値と出力値は、関数によって変更されるデータ構造です。 多くの言語では、関数は命令のシーケンスです。「やったらやる」。 関数の本質を理解するには、これらの命令の実行順序を理解する必要があります（怠（な関数型および論理型言語では、順序は重要ではありません）。
データ構造は単純に存在します。 アクションは実行されません。 それらは排他的に宣言的です。 データ構造の「理解」は、機能の「理解」よりも何倍も簡単です。
関数は、入力を出力に変換するブラックボックスで表されます。 入力と出力を理解すれば、関数を理解できます（ただし、この関数を作成できるという意味ではありません）。
通常、関数は、タイプT1のデータ構造からタイプT2のデータ構造にデータを転送するコンピューターシステムの一部として「理解」されます。
機能とデータ構造はまったく異なる種類の動物であるため、それらを1つの「セル」に入れるという決定は根本的に間違っています。
異議第2 すべてがオブジェクトでなければなりません
「時間」を考慮してください。 オブジェクト指向プログラミング言語では、「時間」はオブジェクトでなければなりません。 しかし、オブジェクト指向言語では、「時間」はデータ型のインスタンスです。 たとえば、Erlangにはさまざまな種類の「時間」があり、それぞれを厳密かつ明確に定義できます。 たとえば、次のタイプ定義を使用します。
-deftype day() = 1..31 -deftype month() = 1..12. -deftype year() = int(). -deftype hour() = 1..24. -deftype minute() = 1..60. -deftype second() = 1..60. -deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}. -deftype hms() = {hms, hour(), min(), sec()}. ...
これらの定義は特定のオブジェクトに属さないことに注意してください。 これらは一般に制限なしで使用されるため、「時間」を表すそのようなデータ構造はどの関数でも使用できます。
また、関連付けられたメソッドはありません。
異議第3 オブジェクト指向言語では、型定義はどこにでもあります
オブジェクト指向プログラミング言語では、データ型定義はオブジェクトに属します。 したがって、すべてのデータ型定義を1か所で見つけることはできません。 ErlangまたはCでは、すべてのデータ型を単一のインクルードファイルまたはデータディクショナリで定義できます。 オブジェクト指向プログラミング言語では、これを行うことはできません。データ型の定義はどこにでもあります。
例を挙げましょう。 グローバルに表示可能なデータ型を定義するとします。
実践プログラマーとLispプログラマーが示したように、多くのデータ型とそれらと連携する少数の関数ではなく、一般的に使用されるデータ型とこのデータと連携する多くの小さな関数を少数持つ方が良いです。
この場合、一般的に使用されるタイプは、リンクリスト、配列、ハッシュテーブル、または時刻、日付、ファイル名などのより複雑なエンティティです。
オブジェクト指向プログラミング言語では、一般的に使用されるデータ構造を定義する基本クラスを選択する必要があります。 このデータ構造を使用する他のすべてのクラスは、このクラスを継承する必要があります。 ここで、この構造が属する「time」タイプのオブジェクトと、「time」タイプのオブジェクトを作成したいとします。
異議第4 オブジェクトには非表示状態があります。
状態はすべての問題の基礎です。 特に、副作用のある機能を避ける必要があります。
プログラミング言語の状態が望ましくないとき、状態は現実の世界で支配的です。 銀行口座のステータスに興味があるため、銀行口座から入金または引き出しを行うと、口座のステータスが正しく更新されることを期待しています。
プログラミング言語は、現実世界のこの状態で動作するために何を提供できますか？
- オブジェクト指向プログラミング言語は「-プログラマーから状態を隠す必要がある」と言うでしょう。 状態は非表示であり、それらへのアクセスは特別な機能を使用してのみ取得できます。
- 従来のプログラミング言語（C、Pascal）は、状態変数の可視性は、言語のスコープのルールによって管理されるべきだと言うでしょう。
- 宣言型言語は、状態がないと言います。
システムのグローバルな状態は、すべての機能に保存され、すべての機能に従います。 モナド（関数型言語の場合）やDC文法（論理言語の場合）などのメカニズムが使用されます。 これらのメカニズムは、プログラマーから状態を隠し、状態を考慮せずにプログラミングできるようにすると同時に、必要に応じて状態にアクセスできるようにします。
オブジェクト指向プログラミング言語に選択された「プログラマから状態を隠す」アプローチは、可能な限り最悪のアプローチです。 状態を開いてコードへの影響を最小限に抑える代わりに、それは重要でないかのように隠れています。
OOPが人気があるのはなぜですか？
- 理由1-誰もが簡単に学べると考えている。
- 理由2-コードの再利用度を高めるために使用できると誰もが考えています。
- 理由3-OOPに関するHYIP。
- 理由4-新しいプログラミング産業を生み出します。
個人的に、私は第一と第二の理由の証拠を見ていません。 その理由は、テクノロジーの背後にあるものです。 プログラミング言語の技術が非常に悪く、この新しい産業を創るという問題を解決するために新しい産業が生まれるなら、これは仕事ではなくお金を稼ぎたい人々にとって大当たりです。
これがオブジェクト指向プログラミングを本当に推進するものです。
翻訳者から。
オリジナル：ジョーアームストロング、 ここから撮影。
特定の考古学およびプログラマーサークルのセンセーショナルは、Erlangの著者であるJoe Armstrongによって書かれたテキストです。 テキストを書く日付を確実に確立することはできませんでしたが、間接データによって判断すると、これは90年代前半でした。