I metodi che accettano i parametri di Collection dovrebbero filtrare la raccolta da soli o essere passati a una raccolta filtrata?

0

Dire che ho questa ragionevole situazione inventata:

    public class Toast
    {
        public bool Toasted { get; set; }
        public int MinutesToHeat { get; set;}
    }

    public class Toaster
    {
        private Heating _heating;

        public Toaster(Heating heating)
        {
            _heating = heating;
        }

        public void SetHeating()
        {
            List<Toast> toast = new List<Toast>()
            {
                new Toast(){Toasted = true},
                new Toast(){Toasted = false},
                new Toast(){Toasted = false},
            };

            _heating.HeatAgain(toast);
            // or
            _heating.HeatAgain(toast.Where(ts => !ts.Toasted).ToList());
        }
    }

È possibile implementare HeatAgain in diversi modi:

Per filtrare nel metodo:

    public class Heating
    {

        public void HeatAgain(List<Toast> args)
        {
            foreach (var toast in args.Where(arg => !arg.Toasted))
            {
                toast.MinutesToHeat += 5;
            }

        }
    }

Oppure ti aspetti un argomento filtrato:

    public class Heating
    {
        public void HeatAgain(List<Toast> args)
        {
            foreach (var toast in args)
            {
                toast.MinutesToHeat += 5;
            }
        }
     } 

In questo caso, la responsabilità di trasmettere gli argomenti corretti è responsabilità del chiamante, del chiamante o di entrambi?

Riesco a vedere che per le API pubbliche, è necessario eseguire la convalida di tutti gli input sul lato del chiamante, ma nel caso della libreria interna e della logica aziendale ciò sembra molto meno definito. Il filtraggio sul chiamante e la verifica degli argomenti sul callee sarebbero i più sicuri, ma darebbero una penalizzazione delle prestazioni, implicherebbe anche che il destinatario debba sapere qualcosa sulle proprietà del chiamante.

Quali sono alcuni buoni modi per valutare l'equilibrio ottimale tra Single Responsibility, performance e validation in casi come questo?

    
posta 3DPrintScanner 05.12.2018 - 15:24
fonte

2 risposte

2

Aspettarsi un argomento filtrato significherebbe che la conoscenza se riscaldare o meno un elemento di pane tostato deve risiedere nel chiamante. Dal momento che il metodo di cui parliamo riguarda il riscaldo del brindisi, questo ha poco senso: la conoscenza strettamente correlata allo scopo di un metodo dovrebbe sicuramente risiedere all'interno del metodo piuttosto che con la sua API pubblica .

I due motivi più importanti per questo sono (1) se ogni chiamante deve conoscere la condizione, la conoscenza sarà duplicata in diversi punti dell'applicazione; (2) spingendo il più possibile la complessità nella gerarchia delle chiamate, si crea un'API con meno precondizioni, il che si traduce in una complessità ridotta per tutti livelli superiori - e la complessità è la ragione più importante perché le basi di codice diventano difficili da utilizzare.

    
risposta data 05.12.2018 - 15:30
fonte
0

Il nome HeatAgain suggerirebbe che il metodo aspettasse la possibilità di Toast di istanze che sono già state tostate. Pertanto, lo filtrerei all'interno di HeatAgain direttamente.

Detto questo, non c'è motivo per te di avere un metodo HeatAgain . Il metodo dovrebbe essere Bake , e per questo metodo, passeresti tu stesso l'elenco filtrato . Se qualcosa Bake genererebbe un'eccezione se viene fornita un'istanza di Toast che è già stata tostato.

    
risposta data 05.12.2018 - 15:31
fonte