Nel pensare al principio di "essere conservatore in ciò che mandi e liberale in ciò che accetti", in genere cerco di rendere i miei metodi ricevuti IEnumerable parametri, ma di emettere un IReadOnlyCollection (eccetto dove l'esecuzione posticipata è veramente prezioso, quindi emetto un IEnumerable ).
Tuttavia, ho appena realizzato che quando si specificano i metodi in un'interfaccia, questo potrebbe essere invertito. È vero?
Le mie specifiche di interfaccia dovrebbero essere indicative a tutti gli implementatori "Ti darò un IReadOnlyCollection , ma puoi semplicemente restituirmi il vecchio IEnumerable indietro"? (Anche in questo caso, se l'esecuzione differita ha senso, fornirei invece un IEnumerable come tipo di parametro). Questo rende tali metodi al contrario, accettando un insieme ristretto / conservativo ma emettendo uno generico / liberale. Tuttavia, questo mi sembra giusto perché con l'inversione della dipendenza, in realtà gli argomenti di input quando viene chiamato il metodo sono in realtà gli argomenti di output del sistema principale (specificando l'interfaccia).
Mi sto solo chiedendo se il mio modo di pensare sia corretto o meno. Sembra che rendere il lato implementatore il più semplice possibile sia davvero il vantaggio.
Mi sto rendendo conto che parte del problema deriva dalla mia preoccupazione di non richiedere agli implementatori di riflettere profondamente sul fatto che l'esecuzione differita abbia un senso o meno. Sapere quando un enumerabile sarà enumerato può essere molto importante in un sistema, e con la separazione delle preoccupazioni che un'interfaccia può aiutare a portare al codice, non vorrei essere così liberale in ciò che il metodo dell'interfaccia produce (che è in definitiva un input al sistema principale) che IEnumerable s impropriamente differito viene gettato in giro ...
Non si tratta di velocità . Non sono sicuro del motivo per cui è stato sollevato, ma per favore non pensarci nemmeno per un secondo sulle implicazioni di performance qui. Questa non è la domanda.