Czy dobrze jest zastosować takie podejście do przechowywania listy ciągów tylko do odczytu, na przykład listy pól w ADO.NET.Lista ciągów tylko do odczytu
var list = new System.Collections.ObjectModel.ReadOnlyCollection<string>(
new List<string>(4) { "type", "currency", "date", "amount" });
A może to zbędne rozwiązanie?
Zależy od twojej pozycji. ReadOnlyCollection działa bardzo dobrze, gdy masz wewnętrzną listę do modyfikacji, która musi być podana do innego kodu, który nie może zmienić listy. Dla prostego kodu, użycie ReadOnlyCollection jest prawdopodobnie przesadą. Jeśli kod jest duży i istnieje ryzyko, że jakiś inny programista (lub ty, w dół drogi) może przypadkowo spróbować zmodyfikować listę, to może być tego warta.
W skrócie: nie używaj idiomatycznie ReadOnlyCollection, użyj go, gdy ma to sens.
Jeśli to możliwe, preferuj sprawdzanie typu statycznego. IEnumerable<string> jest tylko do odczytu.
IEnumerable<string> list = new List<string> { "type", "currency", "date", "amount" };
Późniejsza kod nie może modyfikować listę, a błędy zostaną złowione w czasie kompilacji - chyba użyć refleksji, ale potem odbicie mogłyby zostać wykorzystane w celu obejścia kontroli w czasie wykonywania, jak również.
Wracając do .NET 2.0, klasa Listy miała metodę AsReadOnly(). Kiedy pojawiły się generics, List<T> też. Oto MSDN reference page.
Nie, nie używaj tego, ponieważ kolejny kod może po prostu wrócić do 'Listy'; odbicie nie jest wymagane. –
@KevinBrock Nawet jeśli wymagana byłaby refleksja, byłoby zero wysiłku, aby ominąć, zobacz: http://stackoverflow.com/a/1232332/27423 - próba "zablokowania" rozpakowania twojego "tylko do odczytu" opakowania jest gorsza niż bezużyteczny. To zwiększa złożoność (i może koszt runtime) bez dodawania żadnej rzeczywistej wartości. Dokumentuj poprawne użycie twojego API przez system typu statycznego - cokolwiek innego jest bezcelowe. –