¿Está bien tener muchas clases abstractas en su aplicación?

Inicialmente, queríamos implementar un patrón de estrategia con diferentes implementaciones de los métodos en una interfaz común. Estos se recogerán en tiempo de ejecución en función de las entradas del usuario.

Como resultado, tenemos clases abstractas que implementan 3 - 5 métodos comunes y solo queda un método para una implementación variable, es decir, la Estrategia.

Actualización: por muchas clases abstractas quiero decir que hay 6 funcionalidades diferentes de alto nivel, es decir, 6 paquetes, y cada uno tiene su interfaz + AbstractImpl + (serie de Impl real).

¿Es este un mal diseño de alguna manera?

Cualquier opinión negativa en términos de extensibilidad posterior: me estoy preparando para una revisión de código / diseño con personas mayores.

No, de ninguna manera es un mal diseño. Es un patrón de método de plantilla .

Está destinado a encapsular el comportamiento variable de un paso de algoritmo, que probablemente sea el caso en su escenario. Los patrones de estrategia y método de plantilla hacen una fuerte combinación en muchos casos. Probablemente tenga estrategias abstractas como marco y utilice el patrón de método de plantilla para estrategias concretas. Eso está bastante limpio.

Es extensible y tampoco necesita repetir código. Cuando necesite algo completamente diferente, simplemente use la interfaz de estrategia para crear una nueva estrategia abstracta o concreta.

No, puede estar bastante bien (dependiendo de los detalles; es difícil decir más con este pequeño conocimiento sobre su caso concreto). Está perfectamente bien unificar implementaciones de métodos comunes en una clase base abstracta.

Dependiendo de cómo se use el método abstracto único en sus clases, este patrón podría ser un método de Plantilla en lugar de una Estrategia . Es decir, si se llama por algún otro método final en la clase base, en lugar de hacerlo directamente por el mundo externo.

Los patrones de método de plantilla hacen que la subclase implemente código especial por método abstracto y la subclase hereda el método común de la superclase. Entonces, no creo que esto tenga muchas clases abstractas, es solo una clase abstracta, todas las subclases son clases de instancia.

Si las clases abstractas implican los mismos métodos, con el mismo contenido, ¿por qué tener múltiples clases abstractas?

Si están implicando los métodos de manera diferente, entonces no veo un problema.

Para mejorar la extensibilidad, use interfaces, entonces no es un problema si luego descarta las clases abstractas