Memorizzare IEnumerable come variabile di istanza - è un odore di codice aspettarsi che cambi?

4

Ho qualcosa che funziona come una lista di dimensioni fisse - in realtà si chiama FixedSizeStack<T> nel mio programma. Lo userò per rappresentare gli ultimi X eventi accaduti. Questo elenco di eventi verrà quindi esaminato da diversi osservatori e, se rileveranno i pattern, attiveranno un'azione.

Naturalmente, non vedo alcun motivo per loro di conoscere FixedSizeStack<T> - a me ha senso presentarlo alle azioni come IEnumerable. Sto considerando di dare loro questa lista di eventi nei loro costruttori, quindi chiamare qualcosa come PreviewEvent(Event e); e EventOccured(); e andranno a scorrere su questo IEnumerable.

Mi sento un po 'nauseato enumerare questo IEnumerable più volte, e rendendolo parte del contratto che cambia l'enumerazione - pensi che questo sia un metodo ragionevole?

    
posta Max 11.07.2012 - 19:10
fonte

2 risposte

8

Non penso che sia un odore di codice. Le interfacce IEnumerable (e IEnumerable<T> ) sono semplicemente descritte come:

Exposes the enumerator, which supports a simple iteration over a collection of a specified type. - MSDN

È una collezione e espone un enumeratore. Non c'è nulla nel contratto che implichi che ogni volta che si accede all'enumeratore, esso restituisca la stessa sequenza di elementi. Probabilmente un po 'non convenzionale, ma totalmente corretto.

Spetta al consumatore fare assunzioni o avere requisiti su un riferimento a una raccolta che viene passata. Se il consumatore non vuole davvero che l'elenco cambi in modo imprevisto, deve chiamare immediatamente .ToList() o .ToArray() .

    
risposta data 11.07.2012 - 19:18
fonte
0

Sarebbe più semanticamente corretto includere l'oggetto IEnumerable come parametro passato al gestore di eventi.

    
risposta data 11.07.2012 - 19:16
fonte

Leggi altre domande sui tag