アプリケーションに多くの抽象クラスを入れても大丈夫ですか？

最初は、Commmonインターフェースのメソッドのさまざまな実装でStrategyパターンを実装したいと考えていました。これらは、ユーザー入力に基づいて実行時に取得されます。

結局のところ、3〜5個の一般的なメソッドを実装する抽象クラスがあり、さまざまな実装、つまり戦略に残されているメソッドは1つだけです。

更新：多くの抽象クラスとは、6つの異なる高レベルの機能、つまり6つのパッケージがあり、それぞれにInterface + AbstractImpl +（一連の実際のImpl）があることを意味します。

これは何か悪いデザインですか？

後の拡張性に関する否定的な見解-私は、高齢者とのコード/デザインレビューの準備をしています。

いいえ、これは決して悪いデザインではありません。これは、テンプレートメソッドパターンです。

これは、アルゴリズムステップのさまざまな動作をカプセル化するためのものであり、これはおそらくシナリオに当てはまります。多くの場合、戦略とテンプレートメソッドのパターンは強力な組み合わせになります。おそらく、フレームとして抽象的な戦略があり、具体的な戦略にはテンプレートメソッドパターンを使用します。それはかなりきれいです。

それは拡張可能であり、コードを繰り返す必要もありません。まったく異なるものが必要な場合は、戦略インターフェースを使用して、新しい抽象的または具体的な戦略を作成します。

いいえ、それはまったく問題ありません（詳細によっては、具体的なケースに関するこの小さな知識ではこれ以上言うことは困難です）。一般的なメソッドの実装を抽象基本クラスに統合することは、まったく問題ありません。

クラスで単一の抽象メソッドがどのように使用されるかに応じて、このパターンは戦略ではなくテンプレートメソッドになる場合があります。つまり、外部の世界から直接ではなく、基本クラスの別のfinalメソッドによって呼び出された場合。

テンプレートメソッドパターンはサブクラスに抽象メソッドによる特別なコードを実装させ、サブクラスはスーパークラスから共通メソッドを継承します。だから私はこれが多くの抽象クラスを持っているとは思いません、それはただ一つの抽象クラスであり、すべてのサブクラスはインスタンスクラスです。

抽象クラスが同じメソッドで同じコンテンツを使用している場合、複数の抽象クラスがあるのはなぜですか？

それらがメソッドを異なる方法で実行している場合、問題は発生しません。

インターフェースを使用して拡張性を向上させるには、抽象クラスをスクラップしても問題は少なくなります。