Un elenco <T> dovrebbe essere privato?

Question

Ho bisogno della tua opinione su questo perché ho letto molte cose diverse sull'argomento. Se disponi di un List<T> o di un qualsiasi tipo di elenco all'interno di una dichiarazione di classe, lo rendi privato e quindi aggiungi o rimuovi elementi utilizzando metodi specifici o lo rendi pubblico?

Le vostre opinioni sarebbero molto apprezzate con eventuali svantaggi/vantaggi di ciascuna opzione.

Per fare un esempio, diciamo che abbiamo un con campi privati ​​name e List<Employees>. La mia domanda è se dovremmo rendere la lista dei dipendenti privata o pubblica e quali sono i vantaggi/svantaggi in entrambi i casi.

Answer 1

per List esplicitamente sì dovrebbe essere privato a seconda di cosa si suppone che la funzionalità che si espone, interfacce come IEnuemerable, ICollection o IList sarebbe una scelta migliore o se si espone una raccolta Vedi risposta SLaks .

Generalmente l'esposizione della struttura e dello stato interni è una cattiva idea e poiché l'oggetto di tipo Elenco è entrambi, si vorrebbe mantenerlo interno. Potrebbe avere senso dare all'utente la possibilità di scorrere su di esso, aggiungere o rimuovere elementi, ma si dovrebbe comunque mantenere l'Elenco interno ed esporre i metodi Aggiungi/Rimuovi o come minimo esporre un'interfaccia che permetta di cambiare il tipo di rappresentazione interna senza influire sull'interfaccia pubblica.

Inoltre, se si espone utilizzando un'interfaccia, è consigliabile utilizzare l'interfaccia più ristretta possibile.

Quindi, se il codice client deve solo enumerarlo. utilizzare IEnumerable se il codice client deve indicizzare utilizzare ICollection e così via.

ulteriormente se si espone come IEnumerable si dovrebbe fare in modo che ciò che mai ritorni è in realtà solo leggere o utilizzando una unica classe di raccolta leggere o mediante l'uso di un blocco iteratore

EDIT dopo l'aggiornamento Per quanto riguarda il tuo esempio. Chiediti ha senso che chiunque tranne il datore di lavoro possa cambiare chi sono i suoi dipendenti? per me è nelle parole che hai già scelto. Il Datore di lavoro si avvale del Dipendente e dovrebbe avere il pieno controllo su chi siano i suoi/suoi dipendenti.Quindi in questo caso particolare lo terrei privato ed esporrò il noleggio (impiegato IEmployee) e Fire (impiegato IEmployee) in questo modo il codice dichiara chiaramente l'intento

Answer 2

Se è necessario esporre una raccolta agli utenti della classe, è necessario creare una proprietà readonly con System.Collections.ObjectModel.Collection<T>.

È quindi possibile ereditare questa classe e sovrascrivere InsertItem, RemoveItem, e SetItem per eseguire logica personalizzata quando l'utente manipola la collezione.

Se non si desidera che l'utente possa modificare la raccolta, è necessario esporre uno ReadOnlyCollection<T>.

Nell'esempio specifico, è consigliabile esporre uno ReadOnlyCollection<Employee> con metodi di mutatore separati in Employer.

Answer 3

Dipende dalla funzionalità desiderata. Se si desidera che le persone siano in grado di manipolare l'elenco, è possibile esporlo tramite una proprietà di sola lettura (senza il setter). Se si desidera eseguire codice aggiuntivo quando gli utenti manipolano l'elenco, è necessario scrivere i propri metodi e non esporre l'elenco.

Answer 4

Come per il catalogo refactoring è sempre meglio incassare le collezioni. Ciò impedisce ad alcuni di accidentalmente di esporre i dati aggiungendo o rimuovendo elementi dalla lista. Se non hai bisogno della funzionalità di proteggere i tuoi dati da modifiche accidentali, puoi restituire un elenco normale.

Esponendo i metodi Aggiungi e Rimuovi si ottiene il vantaggio che eventuali modifiche avvengono solo tramite questi metodi.

Answer 5

E se tutto ciò che si desidera è che qualcuno possa enumerare l'elenco, è possibile esporre un iEnumerable la cui funzione GetEnumerator chiama semplicemente la funzione GetEnumerator dell'elenco.