これについての議論をどこかで見たのを覚えています。現在、私が取り組んでいるシステム内のすべてのビジネス オブジェクトが継承するベース オブジェクトを削除することを検討しています。これには、いくつかのプロパティ、いくつかのデータベース ロジック、およびいくつかのコンストラクタ ロジックが含まれています。
これはアンチパターンですか、それとも陪審はまだ出ていませんか? 各オブジェクトで一定量のボイラープレートコーディングを行う必要がある、継承元の基本コントラクトを用意したほうがよいでしょうか?
編集：私はdsimchaが好きで、問題に非常によく反映されていると感じています。さらに回答があればうれしいです
標準的な経験則では、継承はポリモーフィズムを通じてクラスのユーザーに柔軟性を提供する場合にのみ使用し、他のクラスのコードを再利用する場合は合成を使用します。ただし、リスコフの置換原則に違反していない限り、おそらくそれほど悪くはありません。ボイラープレートを大量に記述することも、本質的に悪いことです。実際のアクションが発生しているコードの部分がわかりにくく、DRY に対応していないからです。ただし、リスコフの置換原則に違反している場合、これは絶対に悪い考えです。
また、どのような問題が発生する可能性があるか、または注意する必要があるかを理解したいと思います
潜在的な問題は、多重継承を使用する場合です。サブクラスは「Eve」クラスの 2 つのインスタンスを継承します。これが、C++ がいわゆる仮想継承をサポートする理由です。
これは頻繁に使用されるイディオムです。たとえば、.Net ではすべてがSystem.Object... から派生し、すべての COM オブジェクトが IQueryInterface インターフェイスを実装します。
真空中のアンチパターンはありません。あなたの「イブクラス」が問題を引き起こしていますか? 削除することで、どのようなメリットが期待できますか? アンチパターンの標準的なリストに載っているかどうかを尋ねることは、実際の問題を特定するのに役立つ場合にのみ役立ちます。