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?