What to do if classes with same interface having similar but different method signature?

Question

What to do if classes with same interface having similar but different method signature?

Let's say I have a project to calculate different costs (to get a total cost at last).

In my program, there is several calculator classes, namely ACostCalculator, BCostCalculator and so on. When a calculate() method is invoked to calculate a cost, a cost container is passed to those cost calculators too. In a good scenario, I can make a CostCalculator Interface for every cost calculators.

However, the calculation for different cost required different resources. In my current program, it make be like:

//getResource() are costly method while several costs need this. So do it outside calculate() method.
ResourceA resourceA = getResourceA(); 
ResourceB resourceB = getResourceB();

CostContainer costContainer = new CostContainer();
CostCalculator aCostCalculator = new ACostCalculator();
...
CostCalculator eCostCalculator = new ECostCalculator();

aCostCalculator.calculate(costContainer);
bCostCalculator.calculate(costContainer)
cCostCalculator.calculate(costContainer, resourceA);
dCostCalculator.calculate(costContainer, resourceA);
eCostCalculator.calculate(costContainer, resourceA, resourceB);

If the signature is exactly the same, I may make a loop conveniently to do it at once. However, since they are similar but different, I can't even make a good interface.

I am not sure if there is good ways to do so. What I can think of is generalizing all calculate() method to into

calculate(CostContainer costContainer, List<Object> resources);

Any ideas? Thanks for answering.

Answer 1

If the resources stay the same for the lifetime of the calculators: pass the resources to the constructor of the calculators.

ResourceA resourceA = getResourceA(); 
ResourceB resourceB = getResourceB();

CostContainer costContainer = new CostContainer();

CostCalculator aCostCalculator = new ACostCalculator();
CostCalculator bCostCalculator = new BCostCalculator();
CostCalculator cCostCalculator = new CCostCalculator(resourceA);
CostCalculator dCostCalculator = new DCostCalculator(resourceA);
CostCalculator eCostCalculator = new ECostCalculator(resourceA, resourceB);

aCostCalculator.calculate(costContainer);
bCostCalculator.calculate(costContainer);
cCostCalculator.calculate(costContainer);
dCostCalculator.calculate(costContainer);
eCostCalculator.calculate(costContainer);

Answer 2

The problem of varying signatures for a common interface sounds a lot like the problem that the Adapter design pattern (object adapter variant) solves:

Applied to your situation, you'd only use adapters to the non-conforming calculators. There are really only two types of adapters, Type1 for signature (costContainer, resourceA) and Type2 for signature (costContainer, resourceA, resourceB). Using your example:

Advantages of adapter are that it's a known design pattern (published by GoF in 1995), it allows eventual calculate(...) methods that have varying signatures. Adapters can be updated dynamically if context changes occur (e.g. resources change).

Disadvantages are obviously the additional classes, the indirection, etc. It's more complicated than the selected answer, but is more flexible particularly if you can't modify the API of the adaptees.