なぜクラスはオブジェクトクラスのみから暗黙的に導出されるのですか？

Question

なぜ私たちが単一のユニバーサルクラスしか必要ない理由に反対する議論はありません。ただし、オブジェクトとアンティオブジェクトクラスなど、2つのユニバーサルクラスがありません。自然と科学では、エネルギーやダークエネルギーのような二重性の概念を見つけます。男女;プラスマイナス;乗算して分割;電子および陽子;統合と派生;そして、セット理論で。二元論には非常に多くの例があり、それ自体が哲学です。プログラミング自体では、デザインパターンの使用方法とは対照的に、作業を実行するのに役立つアンチパターンが表示されます。確かではありませんが、この二重性の概念の有用性は、自由またはゆるいオブジェクトと組み合わせて自分自身を破壊し、それによって記憶を解放するアンチオーバーを作成するゴミコレクターを作成することにあるかもしれません。または、アンチオブジェクトがオブジェクトとともに機能して自己修正プログラミング言語を作成することができます。これにより、安全な自己修正コードを作成し、遺伝子プログラミングを使用して進化的コンピューティングを行い、コードを隠してリバースエンジニアリングを防ぐことができます。

それをオブジェクト指向プログラミングと呼びます。それは制限要因ですか、それともプログラミング言語の形成を理解する上で私が見逃している根本的なものがありますか？

Answer 1

これは、タイトルの質問に答えるための答えにすぎません。

Javaなどの言語には、2つの理由ですべてのクラスがオブジェクトから派生しています。

まず、利用可能な多型の量を増やすため。これは、ジェネリックが言語に追加される前に特に必要でした。オブジェクトがなければ、収集クラスは有用な方法で書くことが不可能です。

第二に、クラスが有効または有用であると予想される多くの方法があり、これらはオブジェクトで収集されます。すべてのクラスがオブジェクトから継承されるようにすることにより、すべてのクラスが同じ最小インターフェイスを実装します。

コメントで述べたように、C ++にはオブジェクトのようなクラスがありません。 C ++は多くの点で型ではないため、上記の問題は適用できません。また、C ++テンプレートは多くの多型を提供し、コレクションの実装に使用されます。

Answer 2

受け入れられた回答はほとんど元の質問をカバーしていると思いますが、二次的な質問に関して（かなり非公式に）いくつかのアイデアを投入することで、それを少し（もしそうかもしれないなら）わずかに補完したいと思います。

継承の観点から、クラスの階層がいくつかのルーツを持つことを防ぐものはありません。他の人々、C ++によって指摘されているように、多くのOO言語は、単一の根の祖先クラスに表現力を制約しません。

ただし、aから タイプ理論 視点（継承とサブタイピングは同じものではないので、おそらくここで主な質問のフレームから抜け出していることを思い出してください）、単一の「トップ」スーパータイプは多くの意味を持つことができます（タイプ理論によって異なりますコース）。たとえば、OCAMLには、すべてのオブジェクト（クラスインスタンスであろうと即時オブジェクトであろうと）に共通のスーパータイプがあります。 < > オブジェクトタイプが空であることを示すために、つまり、メッセージを受け入れません。これは、実際に定義できる最も一般的なオブジェクトタイプのようです。なぜなら、それをより一般的にするために何かを削除することはできないからです。したがって、オブジェクトタイプのこの概念では、すべてのオブジェクトには必然的にスーパータイプがあります。

ルートオブジェクトのデュアルに関して、Scalaは呼ばれるクラスを備えています Nothing, 、不思議なことにも空であり、他のすべてのクラスのサブタイプです。インスタンス化することはできませんが、空のリストを実装するのに十分な有用なセマンティックを保持します。 Nil, 、および等しい List[Nothing] （コメントで指摘されているように、プログラマーはほとんどの場合、その価値を直接使用しない可能性があり、それがそのように有用ではないように見えます）。 Nothing ルートタイプのデュアルと見なすことができます - Any Scalaでは、これらのタイプはクラスをカバーするだけでなく、プリミティブタイプもカバーするため、すべてをアップキャストできるように Any, 、 例えば。

Answer 3

さまざまな種類のものに対してさまざまな方法を定義する必要なく、任意の種類のものを保持できるコレクションを定義する能力は非常に有用です。 C ++のテンプレートにより、単一のソースファイルがさまざまな種類のものを保持できるコレクションタイプを定義することを可能にしますが、コンパイラはコレクション内のすべての種類のものに対してコードを複製する必要があります。代わりに、システム内のほぼすべてのタイプを単一のタイプから導出する場合、そのタイプのものへの参照を保持できるコレクションは、ほぼすべてのタイプのものへの参照を保持できるようになります。

ただし、このアプローチには制限があります。これは、価値とエンティティの区別を曖昧にすることです。特定のオブジェクトを識別して値をカプセル化する参照は、そのセマンティクスを変更することなく、そのオブジェクトのコピーへの参照に置き換えることができます。ただし、エンティティを識別するために使用されるリファレンスは、そのような方法で置き換えることはできません。エンティティ自体は、コピーできないものになります（たとえば、現実世界の何かとのつながりを表す場合）、またはエンティティがカプセル化する場合があります それに存在する一連の参照. 。注意すべき重要なことは、オブジェクトが変更できない場合、または1つの参照だけが存在する場合、および複数の参照が存在する場合にエンティティのように動作する場合、オブジェクトは値として動作することです。

値とエンティティの区別を曖昧にすると、収集タイプが自分の内容を価値またはエンティティと見なすべきかどうかを知ることが困難になります。これにより、次のようなものを実装するコレクションの能力が制限されます equals また clone 便利な方法で。より強力なタイプ/エンティティの区別を作成する言語は、コレクションを言語よりも自動的に行うことができますが、区別は複雑さを追加します。