Il client all'interazione dell'applicazione risulta in interfacce grasse

Question

Il client all'interazione dell'applicazione risulta in interfacce grasse

#1 da (2 voti)

1

Come gestisci le interfacce grasse? Ecco un esempio:

public class TSP
{
    public AddEmployeeContribution(...) {...}
    public AddMatchingContribution(...) {...}
    public CalculateTotal() {...}
    public CalculateEmployeeReturn() {...}
    public CalculateMatchingReturn() {...}
    public CalculateTotalCumulativeContributions() {...}
    public CalculateEmployeeCumulativeContributions() {...}
    public CalculateMatchingCumulativeContributions() {...}
    public CalculateTotalContributionByYear(int year) {...}
    public CalculateEmployeeContributionByYear(int year) {...}
    public CalculateMatchingContributionByYear(int year) {...}
    // numerous other functions related to Savings Plan
}

Usando TSP come radice aggregata, sembra che le classi con cui il client interagisce diventano ingombranti. Non sono sicuro di come evitare un'interfaccia grossa con una singola radice aggregata.

object-oriented design inheritance multiple-inheritance

posta keelerjr12 11.12.2017 - 15:51

fonte

1 risposta

Leggi altre domande sui tag object-oriented design inheritance multiple-inheritance

Dati dinamici dei moduli persistenti Qual è il modo migliore per archiviare i thread dei messaggi?

score 2 · Accepted Answer

Quando guardi le interfacce grasse come quelle che hai lì, la sfida è trovare l'astrazione giusta che ti permetta di romperla in blocchi ragionevoli. L'approccio che guardo va più o meno così:

Ci sono raggruppamenti logici che hanno senso come loro?
Esistono pattern che suggeriscono istanze separate?
C'è un modo per nascondere alcune funzioni / metodi?

Nel tuo caso particolare, sembra che la seconda opzione potrebbe essere un modo valido per andare. Hai un insieme ripetuto di metodi per Total , Employee e Matching contributi. Ciò che mi suggerisce è che in realtà hai tre istanze di un'interfaccia che assomigliano a qualcosa del tipo:

public class TSP 
{
    AddContribution(...) {...}
    Calculate(...) {...}
    CalculateReturn(...) {...}
    CalculateCumulativeContribution(...) {...}
    CalculateContributionByYear(...) {...}
    // ...
}

Potresti avere un'interfaccia genitore che ti consente di accedere alle istanze specifiche:

public class AllTSP
{
    GetTotalTSP() {...}
    GetEmployeeTSP() {...}
    GetMatchingTSP() {...}
}

Sentiti libero di spostare i metodi Add() nell'interfaccia di root invece di tenerlo nell'interfaccia TSP. Il consumatore chiama quindi la tua istanza AllTSP in questo modo:

tsp.GetTotalTSP().CalculateContributionByYear(...)

Spero che questo sia almeno abbastanza utile per far funzionare i tuoi processi mentali. Ho scritto il codice di esempio senza alcuna ipotesi sulla lingua che stavi utilizzando. Se la tua lingua ha delle proprietà (come C #), i getter che ho inserito nell'interfaccia di base potrebbero essere implementati come proprietà e apparire un po 'più puliti.

Alcune persone possono innervosirsi quando fai chiamate a catena come questa. L'unico modo per farlo funzionare davvero è garantire che ci sia un oggetto in ogni fase della catena. Finché la catena è corta (cioè solo un paio di link), allora dovrebbe andare bene. Il pericolo nel concatenamento dei metodi è che se uno qualsiasi dei metodi può restituire null , si avrà un tempo veramente difficile per capire quale fallisce. Se prendi le dovute precauzioni e sei consapevole dei problemi, puoi renderlo sicuro.