「継承の目標は、コード（メソッドのセット）を、それが提供し必要とするエンティティプロパティ（通常はオブジェクト）の最小セットにバインドすることです。」
そうですか？ また、バインドの理由は何ですか？ どのような理由で、これらのメソッドをこのオブジェクトに接続する必要があると結論しますが、パブリックインターフェイスを介して欠落しているプロパティ/パラメーターを取得する他のオブジェクトの一部に他のメソッドを含める必要がありますか？
私はSOLIDとオブジェクトに対する唯一の責任という考えを固守します。 したがって、この場合の継承の階層は、継承の実行が必要な特定の状況に対する責任の明確化です。
ただし、実世界（またはドメイン）のオブジェクトは、いくつかの異なる機能/責任を担うことができるため、クラスシステムへの直接マッピングが機能しない場合があります。 アプリケーションクラスシステム内のこのようなオブジェクトは、ドメインオブジェクトによってサポートされる責任のコレクション/コンテナと見なされます。 このクラスのタスクは、相互の責任を調整することです。 整列は、部分的にはクラスコンテナー内の特定の責任の子孫を通じて部分的に発生します。
記事の例に近い例を示します。
能力
- 撃つ能力
- MANPADSを撮影する能力
- 水泳能力
- 歩行能力
スキル-スキルツリーへのリンクやスキルアイテムのスロットなど、一般的な情報を提供します。
射撃能力-狙いを定める機会を提供します。スキルのスロットには射撃武器が必要です。
MANPADSから撮影する機能-目的の機能の実装を指定します。たとえば、MANPADS画面を描画します。
泳ぐ能力-水に浸ることができ（たとえば、同時に死なずに）、時間スケールを表示します。キャラクターはどうにか水の中を飛びます。
ところで、ここで私は抽象化を見逃しました-動き回る能力、そこからあなたは泳ぐ能力と歩く能力を継承することができます。
次に、特定のキャラクターにスキルセットが含まれます。
キャラクター：
- 移動する現在の能力;
- スキルのリスト：[]。
フットマン（キャラクター）：
- 現在の撮影能力;
- スキルのリスト：[泳ぐ、歩く、MANPADSから撮影する]。
アヒル（キャラクター）：
- スキルのリスト：[泳ぐ]。
キャラクターの責任は、お互いのスキルを調整して切り替えることです。 たとえば、キャラクターが水に入ったとき。 あなたが泳ぐ能力を持っている場合-それをアクティブにし、そうでない場合-絵のキャラクターをdrれさせる。
質問：このセットが大きくなるとどうなりますか？
そして、どのように成長することができますか？
- 新しいスキルを追加します。
- 新しいキャラクターを追加します。
- 既存のキャラクターに、以前は彼の特徴ではなかったスキルを追加します（アヒルにマンパズから撃つように教えます）。
新しいスキル：
たとえば、これらが量的なものである場合、MANPADSは0.6にヒットする確率でショットされ、現在は0.8になります。これらは同じクラスのデータベース内の異なるレコードです。
新しい何か、たとえば剣の場合、いずれにせよ、最初に剣の所有を抽象的に記述する大量のコードが必要です。その後、各キャラクターが独自の詳細を追加します。 必ずしも複雑な修正ではありませんが（キャラクターと彼の相続人の抽象化が適切な場合）。
新しいクラスのキャラクター-ここでは、スキルの組み合わせ、スキルを互いに調整する方法を説明する必要があります。 キャラクターのサブクラスとしてコーディングすると、新しいキャラクターに適応したスキルのサブクラスを個別に選択できます。
既存のものに他のものを追加することはより困難です。なぜなら、 既存のコードの内部コードを再度ソートする必要があります。 そしておそらく、子孫を継承する方が簡単でしょう。
たとえば、ダックは私たちすべてに適していますが、撮影方法がわからないだけです。 これは、この機能を適用する必要があることを意味します。2つのクラスを一度に追加する方が便利な場合があります。SimpleDuckとDuckが撮影できます。 そして、アヒルのクラスでは、娘のアヒルに共通の責任を残すために-泳ぐ能力-アヒルに適応しました：水を保持し、ダイビングするという形で。
難しさのもう1つの側面は、新しい責任（クラス）を追加することです。 それをすべての既存のものに関連付ける必要があります。 潜在的に、このプロセスは無限に進む可能性があり、すでに存在するクラスが多いほど時間がかかります。 これに役立つのはトップダウン設計です。世界があり、キャラクターを作成し、スキルを使ってやり取りできるようにします。 スキルキャラクターは増減できます。
この観点から、mixinは未開発のクラスのようです。 それをより速くし、既存のクラス階層とその構成を再構築しないという願望のために、過小評価されたままでした。