Cosa fare se le classi con la stessa interfaccia hanno una firma di metodo simile ma diversa?

Question

Cosa fare se le classi con la stessa interfaccia hanno una firma del metodo simile ma diversa?

Diciamo che ho un progetto per calcolare costi diversi (per ottenere un costo totale alla fine).

Nel mio programma, ci sono diverse classi di calcolatori, ovvero ACostCalculator, BCostCalculator e così via. Quando viene invocato un metodo calculate() per calcolare un costo, viene passato un contenitore di costi anche a tali calcolatori di costi. In un buon scenario, posso creare un'interfaccia CostCalculator per ogni calcolatrice di costi.

Tuttavia, il calcolo per costo diverso ha richiesto risorse diverse. Nel mio programma in corso, che fanno essere come:

//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); 

Se la firma è esattamente lo stesso, posso fare un ciclo favorevole per farlo in una sola volta. Tuttavia, poiché sono simili ma diversi, non riesco nemmeno a fare una buona interfaccia.

Non sono sicuro che ci siano buoni modi per farlo. Quello che mi viene in mente è generalizzare tutto calculate() metodo per in

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

Tutte le idee? Grazie per aver risposto.

Answer 1

Se le risorse rimangono invariate per la durata di vita dei calcolatori: passare le risorse al costruttore delle calcolatrici.

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

È possibile utilizzare variadic arguments:

public interface CostCalculatorInterface { 
    public void calculate(CostContainer container, Object... resources); 
} 

(o sostituire con un altro Object superclasse di ResourceA e ResourceB).

Nelle classi che implementano l'interfaccia, resources sarà un Object[] così si può fare riferimento a loro come resources[0], resources[1] e così via.

Answer 3

Questo è qualcosa che effettivamente utilizzati con i generici:

Resource resourceA = new ResourceA(); 
    Resource resourceB = new ResourceB(); 
    CostContainer costContainer = new CostContainer(); 
    CostCalculator<Resource> costCalculatorA = new ACostCalculator(); 
    costCalculatorA.calculate(costContainer,resourceA,resourceB); 
    CostCalculator<Resource> costCalculatorB = new BCostCalculator(); 
    costCalculatorB.calculate(costContainer,resourceA); 


interface Resource { 
    //Your code 
} 

class ResourceA implements Resource { 
    //Your code 
} 

class ResourceB implements Resource { 
    //Your code 
} 

class CostContainer { 
    //Your code 
} 

interface CostCalculator<T extends Resource> { 
    void calculate(CostContainer costContainer, T... resources); 
} 

class ACostCalculator implements CostCalculator<Resource>{ 

    @Override 
    public void calculate(CostContainer costContainer, Resource... resources) { 
     System.out.println("Test"); 
    } 
} 

class BCostCalculator implements CostCalculator<Resource>{ 

    @Override 
    public void calculate(CostContainer costContainer, Resource... resources) { 
     System.out.println("Test2"); 
    } 
} 

Answer 4

Il problema di varia firme per un'interfaccia comune suona molto come il problema che le Adapter design pattern (object adapter variant) risolve:

Applicato alla situazione, si utilizzano solo adattatori per le calcolatrici non conformi. Esistono solo due tipi di adattatori, Tipo1 per la firma (costContainer, resourceA) e Tipo2 per la firma (costContainer, resourceA, resourceB). Usando il tuo esempio:

vantaggi di adattatore sono che è un design pattern noto (pubblicato da GoF nel 1995), consente eventuali calculate(...) metodi che hanno firme diverse. Gli adattatori possono essere aggiornati in modo dinamico se si verificano cambiamenti di contesto (ad esempio, le risorse cambiano).

Gli svantaggi sono ovviamente le classi aggiuntive, l'indiretto, ecc. È più complicato della risposta selezionata, ma è più flessibile in particolare se non è possibile modificare l'API degli adattamenti.