Collezione <T> contro Elenco <T> cosa dovresti usare sulle tue interfacce?

Il codice è simile al seguente:

namespace Test
{
    public interface IMyClass
    {
        List<IMyClass> GetList();
    }

    public class MyClass : IMyClass
    {
        public List<IMyClass> GetList()
        {
            return new List<IMyClass>();
        }
    }
}

Quando eseguo Analisi del codice ricevo la seguente raccomandazione.

Avviso 3 CA1002: Microsoft.Design: modifica 'Elenco' in 'IMyClass.GetList ()' per utilizzare Collection, ReadOnlyCollection o KeyedCollection

Come devo risolvere questo e quali sono le buone pratiche qui?

Per rispondere alla parte "perché" della domanda sul perché no List<T>, i motivi sono a prova di futuro e semplicità API.

A prova di futuro

List<T>non è progettato per essere facilmente estensibile tramite la sottoclasse; è progettato per essere veloce per le implementazioni interne. Noterai che i metodi su di esso non sono virtuali e quindi non possono essere sovrascritti e non ci sono hook nelle sue operazioni Add/ Insert/ Remove.

Ciò significa che se in futuro è necessario modificare il comportamento della raccolta (ad es. Per rifiutare oggetti null che le persone cercano di aggiungere o per eseguire lavori aggiuntivi quando ciò accade, ad esempio l'aggiornamento dello stato della classe), è necessario modificare il tipo di raccolta che ritorni a una sottoclasse, che sarà una rottura dell'interfaccia (ovviamente cambiare la semantica di cose come non consentire null può anche essere una modifica dell'interfaccia, ma cose come l'aggiornamento del tuo stato di classe interno non lo sarebbero).

Quindi restituendo una classe che può essere facilmente sottoclassata come Collection<T>o un'interfaccia come IList<T>, ICollection<T>oppure IEnumerable<T>è possibile modificare l'implementazione interna in un tipo di raccolta diverso per soddisfare le proprie esigenze, senza violare il codice dei consumatori perché può essere comunque restituito come il tipo che si aspettano.

Semplicità API

List<T>contiene molte operazioni utili come BinarySearch, Sorte così via. Tuttavia, se questa è una raccolta che stai esponendo, è probabile che controlli la semantica dell'elenco e non i consumatori. Quindi, sebbene la tua classe internamente possa aver bisogno di queste operazioni, è molto improbabile che i consumatori della tua classe vogliano (o addirittura dovrebbero) chiamarli.

Pertanto, offrendo una classe o un'interfaccia di raccolta più semplice, riduci il numero di membri che gli utenti della tua API vedono e ne semplifica l'utilizzo.

Dichiarerei personalmente di restituire un'interfaccia piuttosto che una raccolta concreta. Se si desidera davvero l'accesso all'elenco, utilizzare IList<T>. Altrimenti, considera ICollection<T>e IEnumerable<T>.

Non credo che nessuno abbia ancora risposto alla parte "perché" ... quindi ecco qui. Il motivo "perché" tu "dovresti" usare un Collection<T>invece di a List<T>è perché se esponi un List<T>, allora chiunque abbia accesso al tuo oggetto può modificare gli elementi nell'elenco. Considerando che Collection<T>dovrebbe indicare che stai creando i tuoi metodi "Aggiungi", "Rimuovi", ecc.

Probabilmente non dovrai preoccuparti, perché probabilmente stai codificando l'interfaccia solo per te (o forse alcuni colleghi). Ecco un altro esempio che potrebbe avere senso.

Se si dispone di un array pubblico, ad esempio:

public int[] MyIntegers { get; }

Lo penseresti perché c'è solo un accessor "get" che nessuno può fare confusione con i valori, ma non è vero. Chiunque può modificare i valori al suo interno in questo modo:

someObject.MyIngegers[3] = 12345;

Personalmente, userei solo List<T>nella maggior parte dei casi. Ma se stai progettando una libreria di classi che stai per distribuire a sviluppatori casuali e devi fare affidamento sullo stato degli oggetti ... allora vorrai creare la tua collezione e bloccarla da lì: )

Si tratta principalmente di sottrarre le proprie implementazioni invece di esporre l'oggetto List da manipolare direttamente.

Non è buona pratica lasciare che altri oggetti (o persone) modifichino direttamente lo stato dei tuoi oggetti. Pensa ai getter / setter di proprietà.

Raccolta -> Per la raccolta normale
ReadOnlyCollection -> Per le raccolte che non devono essere modificate
KeyedCollection -> Quando si desidera invece dizionari.

Come risolverlo dipende da cosa vuoi che faccia la tua classe e dallo scopo del metodo GetList (). Puoi elaborare?

In questo tipo di caso, di solito cerco di esporre la minima quantità di implementazione necessaria. Se i consumatori non hanno bisogno di sapere che stai effettivamente utilizzando un elenco, non è necessario restituire un elenco. Tornando come Microsoft suggerisce una raccolta, nascondi il fatto che stai utilizzando un elenco dai consumatori della tua classe e li isola da un cambiamento interno.

Qualcosa da aggiungere anche se è passato molto tempo da quando questo è stato chiesto.

Quando il tipo di elenco deriva da List<T>anziché anziché Collection<T>, non è possibile implementare i metodi virtuali protetti Collection<T>implementati. Ciò significa che il tipo derivato non può rispondere nel caso in cui vengano apportate modifiche all'elenco. Questo è perchéList<T> presuppone che tu sia consapevole quando aggiungi o rimuovi elementi. Essere in grado di rispondere alle notifiche è un sovraccarico e quindi List<T>non lo offre.

Nei casi in cui il codice esterno ha accesso alla tua raccolta, potresti non avere il controllo di quando un articolo viene aggiunto o rimosso. Pertanto Collection<T>fornisce un modo per sapere quando l'elenco è stato modificato.

Non vedo alcun problema con la restituzione di qualcosa del genere

this.InternalData.Filter(crteria).ToList();

Se ho restituito una copia disconnessa di dati interni o il risultato distaccato di una query di dati, posso restituire in modo sicuro List<TItem>senza esporre alcun dettaglio di implementazione e consentire di utilizzare i dati restituiti in modo conveniente.

Ma questo dipende dal tipo di consumatore che mi aspetto: se si tratta di una griglia di dati simile a quella che preferisco restituire, IEnumerable<TItem> che sarà comunque l'elenco di articoli copiato nella maggior parte dei casi :)

Bene, la classe Collection è in realtà solo una classe wrapper attorno ad altre raccolte per nascondere i loro dettagli di implementazione e altre funzionalità. Suppongo che ciò abbia a che fare con il modello di codifica che nasconde la proprietà in linguaggi orientati agli oggetti.

Penso che non dovresti preoccuparti, ma se vuoi davvero compiacere lo strumento di analisi del codice, fai solo quanto segue:

//using System.Collections.ObjectModel;

Collection<MyClass> myCollection = new Collection<MyClass>(myList);