2013-03-31 19 views
5

Wiele odpowiedzi na pytanie "Multi value Dictionary" proponuje użycie niezmiennej klasy jako TValue w klasie Dictionary<TKey, TValue>.Dlaczego używałbyś niezmiennej wartości w słowniku?

Przyjęty Jon Skeet's answer proponuje klasę Pair z właściwości tylko do odczytu i @teedyay's answer używać niezmienny Tuple.

Jakie są przesłanki (lub możliwe korzyści) takich podejść?

i zabezpieczenia pytanie:
Dlaczego to make TFirst and TSecond readonly jeśli odpowiednie właściwości pierwszego i drugiego nie mają ustawiaczy anyway:

private readonly TFirst first; 
private readonly TSecond second; 

public TFirst First 
{ 
    get { return first; } 
} 

public TSecond Second 
{ 
    get { return second; } 
} 

Aktualizacja:
Używam słowniki z niestandardowych klas dla wartości w nich.
I va lues są aktualizowane.
Jakie są możliwe powody (korzyści) dla mnie, aby stały się niezmienne?

widzę, że Lookup<TKey, TElement> Class jest niezmienna i myśli, że tęsknię za pewne korzyści ze stosowania zapytań LINQ (?)
Jeśli tak, możesz podać mi przykłady czego tęsknię?

+0

Najpierw może nie być ustawiacza, ale nie ogranicza to bezpośredniego ustawienia, jeśli nie jest on tylko do odczytu. – Robert

+1

Jeśli chodzi o odpowiedź od teedyay, to może być tak, że niezmienność 'Tuple' jest przypadkowa, a' Tuple' jest po prostu najprostszym sposobem powiązania dwóch wartości razem. Możliwe, że jest to również przypadkowe w odpowiedzi Jona Skeeta, gdy pisał kod typu "Pair", który napisał na inną okazję. –

+0

Zgadzam się z @DanielFischer, po prostu uważam, że było to przypadkowe dla rozmowy, zwłaszcza że jego implementacja zapewnia zastąpienie GetHashCode. Istnieją ostrzeżenia o nadpisywaniu GetHashCode na zmienne typy. –

Odpowiedz

1

Druga odpowiedź brzmi, że zmienne członkowskie są nadal możliwe do ustawienia bez słowa kluczowego readonly - tylko w obrębie samej klasy, ale nadal jest to możliwe.

BTW, ta klasa wydaje się być solidnym kandydatem na struct.

4

Zasadniczo, niezmienność ułatwia czytanie różnych rzeczy w moim doświadczeniu. Na przykład jednym z największych problemów związanych z klasami Java Calendar i Date jest ich zmienność. Łatwo jest zapomnieć, że są zmienne, pobrać kopię konstruktora, a następnie znaleźć, że coś innego mutuje obiekt, do którego masz odniesienie. Zaczynasz więc przyjmować obronną kopię, nawet jeśli nic nie jest w stanie zmienić obiektu ... to wszystko staje się bardzo irytujące.

Jest oczywiście czas na zmienność - ale w wielu przypadkach niezmienność jest po prostu przyjemniejsza.

Powiązane problemy