- オントロジーの継承は特殊化を示します。これは特定の種類のものです（サッカーボールは球体であり、そのような半径を持っています）。
- 抽象データ型の継承は置換を示します。この事はその事と同じ特性を持ち、そのような振る舞いをします（これはバーバラ・リスコフを代用する原理です）。
- 実装の継承はコード共有に関連しています。このことは、そのことのいくつかのプロパティを取り、この方法でそれらを再定義または補完します。 私の記事「継承について」にあるこのタイプの継承のみ。
これらは3つの異なる関係であり、しばしば対立する関係にあります。 一部またはすべてを要求することは困難ではありません。 ただし、2つ以上のメカニズムをサポートするために1つのメカニズムが必要な場合、問題が発生します。
多くの場合、OOP継承では、正方形と長方形の関係の反例を示します。 幾何学的に、正方形は長方形の特殊化です。すべての正方形は長方形ですが、すべての長方形が正方形ではありません。 Squareクラスのすべてのsは、長さが幅に等しいsの長方形です。 しかし、タイプ階層では、これは逆です：正方形が使用されている場合はいつでも長方形を使用できます（同じ幅と高さの長方形を指定することで）が、長方形が使用されている場合は正方形を使用できません（たとえば、長さと幅を変更することはできません）。
幾何学的プロパティの継承の方向と、正方形と長方形の抽象データ型の プロパティとの間には互換性がないことに注意してください。 これらの2つの次元は、ソフトウェアの実装において互いに完全に無関係です。 実装の継承についてはまだ何も言っていないので、プログラムを書くことすら考えていません。
Smalltalkおよびそれ以降の多くの言語は、単純な継承を使用して実装を継承します。これは、ダイヤモンドの問題のために多重継承がそれと互換性がないためです（特性は、互換性を宣言する信頼できる方法を提供し、問題の解決策を読者の課題として残します）。 一方、正方形は長方形であり、正多角形でもあるため、単純な継承は存在論的継承と互換性がありません 。
Smalltalk Blue Bookは、継承を実装の継承という観点からのみ説明しています。
「サブクラスは、明示的な違いを除いて、そのすべてのインスタンスが、スーパークラスと呼ばれる別のクラスのインスタンスと同じになることを決定します。」欠落している詳細に注意してください。サブクラスのインスタンスがプログラム内のあらゆる場所でスーパークラスのインスタンスを置き換えることができることは言及されていません。 サブクラスのインスタンスがそのスーパークラスのインスタンスのすべての概念テストを満たす必要があることは言及されていません。
継承が問題になったことはありません。問題は、 3つの異なる概念に 1つのツリーを使用しようとしていることです。
「継承よりも構造を優先する」とは、基本的に実装の継承を放棄することです。 どのように機能させるか理解できないため、完全に放棄しましょう。サブクラスではなく、委任によって共有します。
Javaのような言語を使用するためのエッフェルと個別の合理化されたアプローチは、「継承はサブタイプの作成」という関係を強化し、「継承は再利用」という関係を弱めます（ツリーの無関係な部分に同じメソッドが2回現れる場合、プロパティを保持するためにそれと共存する必要があります。各サブクラスはその親のサブタイプである）。 継承ツリーを使用して問題領域をモデル化しようとしていない場合、これは正常です。 通常、OOPの文献では、問題指向の設計に関してこれを推奨しています。
タイプは「継承は特殊化」という関係を強化し、「継承は再利用」という関係を弱めます（両方のスーパーカテゴリがインスタンスの同じプロパティを生成する場合、どちらも継承されず、自分で登録する必要があります）。 サブクラスをスーパークラスの共変サブタイプと見なそうとしない場合、これは正常ですが、OOPの文献では通常、Barbara Liskovの置換原理と、メソッドシグネチャの型がその型またはサブクラスを意味するという事実に言及することでこれを推奨しています。
私は次のことを文献に書くべきだと信じています：「ここに3つのタイプの継承があり、そのうちの1つに焦点を合わせてください。」 言語もこれをサポートするべきだと思います （明らかに、Smalltalk、Rubyとその仲間は、型の制限がないためこれをサポートしています）。
- 継承を使用してコードを共有する場合、サブクラスが同時にサブタイプであると想定しないでください。
- サブタイプを使用してインターフェイスコントラクトを強化する場合、ツリー内の任意のクラスをツリー内の別のクラスのサブタイプとしてマークできるだけでなく、そのようにする必要があります。 繰り返しますが、私のサブクラスが同時にサブタイプであると仮定するべきではありません。
- クラスを通じて概念的な特殊化を指定する必要がある場合、これも継承ツリーへの準拠を意味するものではありません。 ツリーの任意の場所にあるクラスを、ツリーの任意の場所にある別のクラスのサブセットとしてマークできるようにするだけでなく、そうする必要があります。 繰り返しますが、あなたは私のサブクラスが同時に特殊化されていると仮定すべきではありません。
配布エリアモデルはオブジェクトモデルではありません。 これは抽象データ型モデルではありません。 また、オブジェクトモデルは抽象データ型のモデルではありません。
継承が再びシンプルになりました。