Wady obiektów niezmiennych

Question

Wiem, że obiekty niezmienne mają kilka zalet w porównaniu z obiektami zmiennymi, takimi jak łatwiejsze do zrozumienia niż zmiennymi, nie mają złożonych przestrzeni stanów, które zmieniają się w czasie, możemy je swobodnie przesuwać, czynią bezpieczne hash klucze tabeli itp. Tak więc moje pytanie brzmi: jakie są wady niezmiennych obiektów?

Answer 1

Cytując Effective Java:

Jedyną wadą jest to, że klas niezmiennych wymagają one oddzielny obiekt dla każdej odrębnej wartości. Tworzenie tych obiektów może być kosztowne, szczególnie jeśli są one duże. Na przykład załóżmy, że masz milion-bitowego BigInteger i chcesz zmienić jego niska-order bitowe:

BigInteger moby = ...; 
moby = moby.flipBit(0); 

Sposób flipBit tworzy nowy BigInteger instancji, także milion bitów długo, że różni się od oryginału tylko jednym bitem. Operacja wymaga czasu , a przestrzeń proporcjonalna do rozmiaru BigInteger. Porównaj to z java.util.BitSet. Podobnie jak BigInteger, BitSet reprezentuje dowolnie długą długość bitów, ale w przeciwieństwie do BigInteger, BitSet jest zmienna. Klasa BitSet zapewnia metodę, która umożliwia zmianę stanu pojedynczego egzemplarza instancji o wartości miliona na milion w stałym czasie.

Przeczytaj cały artykuł na Item 15: Minimize mutability

Answer 2

Oprócz ewentualnych wad wydajności (możliwie ponieważ ze złożonością GC i HotSpot optymalizacji struktury niezmienne niekoniecznie są wolniej!) - jedna wada może być tak, że państwo musi teraz być połączony z całą aplikacją. W przypadku prostych aplikacji lub małych skryptów wysiłek, aby utrzymać stan w ten sposób, może być zbyt wysoki, aby zapewnić bezpieczeństwo współbieżności.

Na przykład pomyśl o strukturze GUI, takiej jak Swing. Byłoby zdecydowanie możliwe napisanie szkieletu GUI w całości za pomocą niezmiennych struktur i jednej głównej "niebezpiecznej" zewnętrznej pętli, i myślę, że zostało to zrobione w Haskell. Niektóre problemy z utrzymaniem niezmiennego stanu zagnieżdżonego można rozwiązać na przykład za pomocą soczewek. Ale zarządzanie wszystkimi interakcjami (rejestrowanie słuchaczy itp.) Może być dość zaangażowane, więc możesz chcieć wprowadzić nowe abstrakcje, takie jak funkcjonalnie reaktywne lub hybrydowo reaktywne GUI.

Zasadniczo tracisz część enkapsulacji OO, przechodząc przez wszystkie niezmienne, a gdy staje się to problemem, istnieją alternatywne podejścia, takie jak aktorzy lub STM.

Answer 3

Pracuję ze Scala na co dzień. Niezmienność ma pewne kluczowe zalety, jak wszyscy wiemy. Czasami jednak łatwiej jest zezwolić na zmienną zawartość w niektórych sytuacjach. Oto zmyślony przykład:

var counter = 0 
something.map {e => 
    ... 
    counter += 1 
} 

Oczywiście mogę tylko mieć mapa powrócić krotki z ładunkiem i liczyć, lub użyć collection.size jeśli są dostępne. Ale w tym przypadku licznik zmienny jest prawdopodobnie bardziej wyraźny. Generalnie wolę niezmienność, ale pozwalam sobie na wyjątki.

Answer 4

Aby odpowiedzieć na to pytanie chciałbym zacytować Programowanie w Scala, drugie wydanie, rozdział "Kolejne kroki w Scala", pozycja 11, by Lex Spoon, Bill Venners i Martin Odersky:

The perspektywy Scala, jednak , czy val i var to tylko dwa różne narzędzia w twojej skrzynce narzędziowej, zarówno przydatne, ani z natury złe. Scala zachęca cię do skłaniania się w stronę szakali, ale ostatecznie sięgnij po najlepsze narzędzie, biorąc pod uwagę wykonywaną pracę.

Więc chciałbym powiedzieć, że tak jak w przypadku języków programowania, Val i var rozwiązuje różne problemy: nie ma „disavantage/avantage” bez kontekstu, nie jest tylko problem do rozwiązania, a oba val/adres var inaczej problem.

Mam nadzieję, że pomoże, nawet jeśli nie zawiera konkretnej listy plusów/minusów!