0

I have some transaction line items and I need to generate future billing schedules from those line items. Right now there are four different types of line items, each of which requires slightly different billing schedule generation logic. I expect more types of line items in the future.

Currently I have a BillingScheduleGenerator class that accepts a list of line items, sorts the line items, retrieves required configuration information from the database, and fires off the correct billing schedule generation logic for each group of line items.

The problem is that this class is becoming huge.

I think the best solution is to make a series of subclasses like this:

BillingScheduleGenerator

LineItemBillingScheduleGenerator extends BillingScheduleGenerator

PurchaseLineItemBillingScheduleGenerator extends LineItemBillingScheduleGenerator 

CancellationLineItemBillingScheduleGenerator extends LineItemBillingScheduleGenerator 

...

This way the more specific line item generators can share the more general line item generation logic (monthly proration, retrieving pricing information ect.) and the specific generation logic that doesn't need to be shared can be encapsulated in a smaller class.

So the question I'm struggling with now is: where do I put the logic that sorts the line items and retrieves the configuration information from the database?

Should it live inside the LineItemBillingScheduleGenerator super class? That would allow callers to instantiate the LineItemBillingScheduleGenerator with a list of line items, call a single method, and receive a list of billing schedules in return.

Is it 'wrong' for a superclass to instantiate and call each of its sub classes?

Should I just put the sorting and querying logic into a service method?

bafuda
  • 141
  • 1
  • 7
  • 1
    IMHO: If the generation logic is the same for all sub-classes, then put it in the superclass. Otherwise, put it in each sub-class. Of course, if there are common aspects of the process, then extract that into methods that can go in the super class. That way, you avoid code duplication. A super class should have no dependency on any sub-class! You might even consider making your superclass `abstract` – jr593 Jul 24 '17 at 09:59
  • @jr593 thanks! The sub classes share some generation logic; they also share configuration information retrieved from the database. Since retrieving the config info is expensive in this app, I definitely do not want to do the retrieval for each instance of the sub class. Is best approach is to retrieve the config info in a static method and pass it to each instance of the sub class? – bafuda Jul 24 '17 at 12:41

1 Answers1

0

A super class can be instantiated and call its subclasses. In Java, the default parent class of every class is Object class.Every class, by default, extends and inherits the properties of this Object class. Also read about Upcasting and downcastingInheritance .Read these basics elaborately, you will get a good idea about how it is working.

Amal lal T L
  • 400
  • 5
  • 20