Est-il correct d'avoir de nombreuses classes abstraites dans votre application?

Nous voulions initialement implémenter un modèle de stratégie avec différentes implémentations des méthodes dans une interface commune. Ceux-ci seront récupérés lors de l'exécution en fonction des entrées de l'utilisateur.

Il s'est avéré que nous avons des classes abstraites qui implémentent 3 à 5 méthodes communes et une seule méthode pour une implémentation variable, à savoir la stratégie.

Mise à jour: Par de nombreuses classes abstraites, je veux dire qu'il y a 6 fonctionnalités différentes de haut niveau, c'est-à-dire 6 packages, et chacune a son Interface + AbstractImpl + (série d'Impl réelle).

Est-ce une mauvaise conception de quelque façon que ce soit?

Toute opinion négative en termes d'extensibilité ultérieure - Je me prépare pour une révision du code / design avec les seniors.

Non, ce n'est en aucun cas une mauvaise conception. C'est un modèle de méthode de modèle .

Il est destiné à encapsuler le comportement variable d'une étape d'algorithme, ce qui est probablement le cas dans votre scénario. Les modèles de stratégie et de méthode de modèle forment une combinaison solide dans de nombreux cas. Vous avez probablement des stratégies abstraites comme cadre et utilisez le modèle de méthode de modèle pour des stratégies concrètes. C'est assez propre.

Il est extensible et vous n'avez pas non plus besoin de répéter le code. Lorsque vous avez besoin de quelque chose de complètement différent, utilisez simplement l'interface de stratégie pour créer une nouvelle stratégie abstraite ou concrète.

Non, cela peut être tout à fait correct (en fonction des détails - il est difficile d'en dire plus avec ce peu de connaissances sur votre cas concret). Il est parfaitement correct d'unifier les implémentations de méthodes courantes dans une classe de base abstraite.

Selon la façon dont la méthode abstraite unique est utilisée dans vos classes, ce modèle peut être une méthode de modèle plutôt qu'une stratégie . À savoir, si elle est appelée par une autre méthode finale dans la classe de base, plutôt que directement par le monde extérieur.

Les modèles de méthode de modèle font de la sous-classe pour implémenter du code spécial par une méthode abstraite et la sous-classe hérite de la méthode commune de la super-classe. Donc, je ne pense pas que cela ait de nombreuses classes abstraites, ce n'est qu'une seule classe abstraite, toute la sous-classe est une classe d'instance.

Si les classes abstraites implémentent les mêmes méthodes, avec le même contenu, alors pourquoi avoir plusieurs classes abstraites?

S'ils implémentent les méthodes différemment, je ne vois aucun problème.

Pour améliorer l'extensibilité, utilisez les interfaces, alors cela pose moins de problème si vous supprimez ensuite la ou les classes abstraites