J'ai quelques éléments de campagne et j'ai besoin de générer des calendriers de facturation futurs à partir de ces éléments de campagne. À l'heure actuelle, il existe quatre types différents d'éléments de campagne, chacun nécessitant une logique de génération de calendrier de facturation légèrement différente. J'attends plus de types d'éléments de campagne dans le futur. Actuellement, j'ai une classe BillingScheduleGenerator qui accepte une liste d'éléments de ligne, trie les éléments de ligne, extrait les informations de configuration requises de la base de données et déclenche la logique de génération de planification de facturation correcte pour chaque groupe d'éléments de campagne.Une super classe doit-elle instancier et appeler ses sous-classes?
Le problème est que cette classe devient énorme.
Je pense que la meilleure solution est de faire une série de sous-classes comme ceci:
BillingScheduleGenerator
LineItemBillingScheduleGenerator extends BillingScheduleGenerator
PurchaseLineItemBillingScheduleGenerator extends LineItemBillingScheduleGenerator
CancellationLineItemBillingScheduleGenerator extends LineItemBillingScheduleGenerator
...
De cette façon, les générateurs d'éléments de ligne plus spécifiques peuvent partager plus logique générale de génération d'élément de ligne (proratisation mensuelle, la récupération des informations de prix ect.) et la logique de génération spécifique qui n'a pas besoin d'être partagée peut être encapsulée dans une classe plus petite.
Donc la question que je suis aux prises avec est maintenant: où dois-je mettre la logique qui trie les éléments de ligne et récupère les informations de configuration de la base de données?
Devrait-il vivre dans la super classe LineItemBillingScheduleGenerator? Cela permettrait aux appelants d'instancier le LineItemBillingScheduleGenerator avec une liste d'éléments de campagne, d'appeler une méthode unique et de recevoir une liste de calendriers de facturation en retour.
Est-ce une erreur qu'une super-classe instancie et appelle chacune de ses sous-classes?
Dois-je simplement mettre la logique de tri et d'interrogation dans une méthode de service?
IMHO: Si la logique de génération est la même pour toutes les sous-classes, placez-la dans la superclasse. Sinon, mettez-le dans chaque sous-classe. Bien sûr, s'il y a des aspects communs du processus, alors extrayez-le dans des méthodes qui peuvent aller dans la super classe. De cette façon, vous évitez la duplication de code. Une super classe ne devrait dépendre d'aucune sous-classe! Vous pourriez même envisager de faire votre superclasse 'abstract' – jr593
@ jr593 merci! Les sous-classes partagent une certaine logique de génération; ils partagent également les informations de configuration extraites de la base de données. Depuis la récupération de l'information de configuration est cher dans cette application, je ne veux certainement pas faire la récupération pour chaque instance de la sous-classe. La meilleure approche consiste-t-elle à récupérer les informations de configuration dans une méthode statique et à les transmettre à chaque instance de la sous-classe? – bafuda