継承が間違っている

良い継承モデルが下り坂になっているコードがいくつかあり、それを修正する理由と方法を理解しようとしています。基本的に、次のようなZoo階層があるとします。

class Animal  
class Parrot : Animal 
class Elephant : Animal 
class Cow : Animal

等

eat（）、run（）などのメソッドがあり、すべてが適切です。それからある日誰かがやって来て言う-私たちのCageBuilderクラスはうまく機能し、animal.weight（）とanimal.height（）を使用しますが、新しいアフリカバイソンは強すぎて壁を砕くことができるので、追加しますAnimalクラスのもう1つのプロパティ-isAfricanBizon（）で、マテリアルを選択するときにそれを使用し、AfricanBizonクラスに対してのみオーバーライドします。次の人が来て、似たようなことをします。次に、基本クラスへの階層のサブセットに固有のこれらすべてのプロパティがあることを知っています。

そのようなコードを改善/リファクタリングする良い方法は何ですか？ここでの1つの代替方法は、dynamic_castsを使用して型をチェックすることですが、呼び出し元を混乱させ、あらゆる場所にif-then-elseを追加します。ここでは、より具体的なインターフェイスを使用できますが、基本クラス参照のみを使用している場合は、あまり役に立ちません。他の提案はありますか？例？

ありがとう！

この問題は、RequiresConcreteWall（）を実装する代わりに、IsAfricanBison（）を呼び出すフラグを実装し、壁をクラスのスコープ外で変更するかどうかのロジックを移動したようです。クラスは、アイデンティティではなく動作と要件を公開する必要があります。これらのクラスの消費者は、彼らが何であるかに基づいてではなく、彼らが言われたものから働くべきです。

isAfricanBizon（）はジェネリックではありません。また、強すぎる飼育動物飼育場で動物農場を拡張し、isAfricanBizon（）からtrueを返して適切な効果を得るのはばかげているとします。

特定の質問に答えるメソッドを常にインターフェイスに追加したい場合、この場合はstrength（）のようなものになります

あなたの問題はこれだと思います：階層のサブセットのみに関心があるが、基本クラスへのポインター/参照が渡されるライブラリのさまざまなクライアントがあります。それは実際にdynamic_cast <>が解決する問題です。

dynamic_cast <>の使用を最小限に抑えることは、クライアントの設計の問題です。オブジェクトを特別な処理が必要かどうかを判断し、必要であれば、ダウンキャストされた参照に対するすべての操作を行う必要があります。

いくつかの個別のサブ階層に適用される機能の「ミックスイン」タイプのコレクションがある場合、JavaとC＃が使用するインターフェイスパターンを使用できます。純粋仮想クラスである仮想基本クラスを持ち、dynamic_cast <>を使用して、インスタンスがその実装を提供するかどうかを判断します。

できることの1つは、タイプの明示的なisAfricanBison()チェックを、実際に興味のあるプロパティのチェックに置き換えることですisTooStrong()。

動物はコンクリートの壁を気にするべきではありません。たぶん、単純な値で表現できます。

class Animal {
public:
  virtual ~Animal() {}
  virtual size_t height() const = 0;
  virtual size_t weight() const = 0;
  virtual bool isStrong() const = 0;
};

Cage *CreateCageFromSQL(Animal &a);
Cage *CreateCageFromOrangePeelsAndSticks(Animal &a);

しかし、それは現実的ではないと思います。しかし、それはおもちゃの例の問題です。

RequiresConcreteWalls（）や、動的ポインターキャストの行と行は、決して見たくないでしょう。

これは通常、安価なソリューションです。保守と概念化は簡単です。そして本当に、問題はとにかく動物の種類に結びついていると述べています。

class Animal {
public:
  virtual ~Animal() {}
  virtual CageBuilder *getCageBuilder() = 0;
};

これは、共有コードの使用を妨げるものではなく、Animalを少し汚染するだけです。

しかし、ケージがどのように構築されるかは、他のシステムのポリシーかもしれません。また、動物ごとに複数のタイプのケージビルダーがあるかもしれません。あなたが思い付くことができる多くの奇妙で複雑な組み合わせがあります。

私はコンポーネントベースデザインを良い目的に使用しましたが、その主な問題は、Animalの所有権が共有されると面倒になる可能性があることです。デストラクタをスローポイントにしないようにする方法。

ダブルディスパッチも別のオプションですが、私は常にそれに飛び込むことをticしていました。

それを超えて、問題を推測することは困難です。

確かに、すべての動物には固有の特性がありattemptEscape()ます。メソッドの中にはfalse、すべてのシナリオで結果をもたらすものもあれば、などの他の固有の特性の経験則に基づいたチャンスがあるものもsizeありweightます。それから確かにattemptEscape()戻ってくるので、確かにある時点で些細になりtrueます。

私はあなたの質問を完全に理解していないのではないかと心配しています...すべての動物には関連する行動と特徴があります。その動物に特有のものを、適切な場所に導入する必要があります。BisonをParrotsに直接関連付けようとすることは、適切なセットアップではなく、適切な設計では問題になりません。

別のオプションは、各動物に適したケージを作成する工場を使用することです。これは、それぞれの条件が非常に異なる場合に改善できると思います。しかし、これがこの1つの条件である場合は、上記のRequiresConcreteWall()メソッドが実行します。

RequiresConcreteWall（）とは異なり、RecommendCageType（）はどうですか

こんなことしてみませんか

class Animals { /***/ } class HeavyAnimals{} : Animals //The basic class for animals like the African Bison

HeavyAnimalsクラスでは、HeavyAnimalsクラスを拡張することにより、African Bisonクラスを作成できます。

これで、HeavyAnimalクラスなどの他の基本クラスを作成するために使用できる親クラス（動物）を使用して、African Bisonクラスおよび他の重い動物を作成できます。アフリカのバイソンを使用すると、Animalクラスのメソッドとプロパティ（これはすべての動物のベース）にアクセスでき、HeavyAnimalsクラス（これはHeavy Animalsのベース）にアクセスできます。