Co zrobić, jeśli klasy o tym samym interfejsie mają podobny, ale inny podpis metody?

Question

Co zrobić, jeśli klasy o tym samym interfejsie mają podobny, ale inny podpis metody?

Załóżmy, że mam projekt do obliczenia różnych kosztów (aby ostatecznie uzyskać całkowity koszt).

W moim programie jest kilka klas kalkulatora, a mianowicie ACostCalculator, BCostCalculator i tak dalej. Kiedy wywoływana jest metoda calculate() w celu obliczenia kosztu, kontener kosztowy jest również przekazywany do tych kalkulatorów kosztów. W dobrym scenariuszu mogę utworzyć interfejs CostCalculator dla każdego kalkulatora kosztów.

Jednak obliczenia dla różnych kosztów wymagały różnych zasobów. W moim bieżącym programie wygląda to tak:

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

Jeśli podpis jest dokładnie taki sam, mogę wykonać pętlę wygodnie, aby zrobić to za jednym razem. Jednak ponieważ są one podobne, ale różne, nie mogę nawet stworzyć dobrego interfejsu.

Nie jestem pewien, czy istnieją na to dobre sposoby. Co mogę pomyśleć, to uogólniając wszystkie calculate() metodę do

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

Jakieś pomysły? Dzięki za odpowiedź.

Answer 1

Jeśli zasoby pozostaną niezmienione przez cały cykl życia kalkulatorów: przekaż zasoby do konstruktora kalkulatorów.

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

Można użyć variadic arguments:

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

(lub zastąpić Object z innym nadklasą ResourceA i ResourceB).

W klasach realizujących interfejs resources będzie Object[] więc można odnosić się do nich jak resources[0], resources[1] i tak dalej.

Answer 3

To jest coś, co można faktycznie korzysta z rodzajowych:

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

Problem z różnych podpisów dla wspólnego interfejsu brzmi to jak problem, że Adapter design pattern (object adapter variant) rozwiązuje:

W zależności od sytuacji używałbyś tylko adapterów do nieodpowiednich kalkulatorów. Istnieją tak naprawdę tylko dwa typy adapterów, Type1 dla podpisu (costContainer, resourceA) i Type2 dla podpisu (costContainer, resourceA, resourceB). Korzystanie z przykładem:

Zalety karty jest to, że jest to znany wzorzec projektowy (opublikowana w 1995 roku przez GOF), pozwala na ewentualne calculate(...) metody, które mają różne podpisy. Adaptery mogą być aktualizowane dynamicznie, jeśli wystąpią zmiany kontekstu (np. Zmiana zasobów).

Wadami są oczywiście dodatkowe zajęcia, niedostrzeganie itp. Jest to bardziej skomplikowane niż wybrana odpowiedź, ale jest bardziej elastyczne, szczególnie jeśli nie można zmodyfikować interfejsu API adaptesów.