Różnica między obiektem sprawy a obiektem

226

Czy jest jakaś różnica między obiektem sprawy a obiektem w scali?

scala

3

Ma rację - nie trzeba mieć obiektu sprawy, aby móc na nim dopasować wzór. Myślę, że nie zostało to rozwiązane w poprzednim pytaniu ...

— axel22,

3

Myślałem, że będzie różnica w zachowaniu dopasowania wzorca, ale zarówno obiekt sprawy, jak i obiekt normalny zachowują się w ten sam sposób w dopasowaniu wzorca AFAIK. Trudno jest znaleźć jakiekolwiek informacje na temat obiektów sprawy, więc nie mogę się doczekać, aby ktoś nas oświecił.

— Wiek Mooij,

4

caseAby dopasować wzór, nie trzeba go używać , to tylko cukier. Wcielanie unapplysię w życie wykonuje zadanie.

— Raphael

1

Przyjęta odpowiedź po prostu nie odpowiada na pytanie, jak omówiono w komentarzach do niego. Zbyt późno, aby coś zmienić, ale należy to zauważyć.

— itsbruce

Nie jest za późno na edycję zaakceptowanej odpowiedzi. Edycja zostanie sprawdzona i, w razie potrzeby, zaakceptowana.

— C4stor

111

Klasy przypadków różnią się od klas zwykłych tym, że otrzymują:

obsługa dopasowywania wzorców
domyślne implementacje equalsihashCode
domyślne implementacje serializacji
ładniejsza domyślna implementacja toStringi
niewielka ilość funkcji, które otrzymują po automatycznym dziedziczeniu scala.Product.

Dopasowywanie wzorców, equals i hashCode nie mają większego znaczenia dla singletonów (chyba że zrobisz coś naprawdę zdegenerowanego), więc właściwie otrzymujesz serializację, fajne toStringi niektóre metody, których prawdopodobnie nigdy nie użyjesz.

— Dave Griffith
źródło

46

Punkty 3 i 4 tej odpowiedzi to poprawna różnica między obiektami sprawy i obiektami. Punkty 1 i 2 nie mają znaczenia dla obiektów singletonowych. A obiekty singletonowe są zawsze Produktami o arity 0, więc punkt 5 również nie ma znaczenia.

— Wojciech Durczyński

86

Ten post utrwala mit, który objectjest taki sam jak singleton. Nie jest. Raczej jest dokładnie tym, co mówi, jest przedmiotem, tj. Deklaracją i instancją w jednym. Ogranicza się objectdo pojedynczej instancji, jeśli jest zdefiniowana w zakresie pakietu, co skutecznie czyni ją singletonem, ale tylko jeśli jest zdefiniowana W TYM ZAKRESIE. Jeśli zdefiniowane w klasie, możesz mieć tyle instancji, co samą klasę (jest ona leniwie utworzona, więc niekoniecznie jest to 1-1). Te wewnętrzne obiekty mogą równie dobrze być używane jako klucze skrótu, co sprawia, że domyślny equals / hashCode jest bardzo sensowny.

— nilskp

66

Pytanie dotyczy case objectnie klasy, dlaczego to poprawna odpowiedź?

— Ixx

10

To nie odpowiada na pytanie. Ta odpowiedź dotyczy różnicy między case classa class. Pytanie dotyczy różnicy między case objecti object.

— MK

6

@ C4stor Odpowiedź jednak tego nie mówi. Obiekt nie jest klasą. Biorąc pod uwagę, że klasy przypadków wykonują spore ilości magii za kulisami, biorąc pod uwagę różne przypadki krawędzi i komplikacje, nie ma powodu po prostu zakładać, że jedyna różnica między standardowym obiektem Scali a obiektem przypadku jest wyjaśniona przez to, co wiemy o różnicy między klasami standardowymi a klasami spraw. Ta odpowiedź nawet nie odnosi się do sformułowania pytania.

— itsbruce

137

Oto jedna różnica - obiekty przypadku rozszerzają tę Serializablecechę, aby można je było serializować. Zwykłe obiekty nie mogą domyślnie:

scala> object A
defined module A

scala> case object B
defined module B

scala> import java.io._
import java.io._    

scala> val bos = new ByteArrayOutputStream                                            
bos: java.io.ByteArrayOutputStream =  

scala> val oos = new ObjectOutputStream(bos)                                          
oos: java.io.ObjectOutputStream = java.io.ObjectOutputStream@e7da60                   

scala> oos.writeObject(B)

scala> oos.writeObject(A)
java.io.NotSerializableException: A$

— axel22
źródło

15

Myślę, że obiekty przypadków mogą być serializowane, to największa różnica od zwykłych obiektów, szczególnie w komunikacji sieciowej między aktorami

— 爱国者

14

Dodawanie extends Serializablepowinno jednak zrobić tę samą sztuczkę.

— nilskp

36

scala> object foo

zdefiniowany obiekt foo

scala> case object foocase

obiekt zdefiniowany

Różnica w serializacji:

scala> foo.asInstanceOf[Serializable]

java.lang.ClassCastException: nie można przesłać foo $ do scala.Serializable
... 43 elided

scala> foocase.asInstanceOf[Serializable]

res1: Serializable = foocase

toString różnica:

scala> foo

res2: foo.type = foo $ @ 7bf0bac8

scala> foocase

res3: foocase.type = foocase

— Minnie
źródło

2

obiekty case domyślnie pochodzą z implementacji metod toString, equals i hashCode, ale proste obiekty nie. obiekty sprawy mogą być serializowane, podczas gdy proste obiekty nie, co sprawia, że obiekty sprawy są bardzo przydatne jako wiadomości z Akka-Remote. Dodanie słowa kluczowego case przed słowem kluczowym object powoduje, że obiekt może być serializowany.

— Prashant_Sharma
źródło

0

Podobnie jest z case classi class, używamy case objectzamiast tego, case classgdy nie ma żadnych pól reprezentujących dodatkowe informacje o stanie.

— szlak wina
źródło

0

Wcześniej znamy obiekty i „klasę przypadków”. Ale „obiekt sprawy” jest mieszanką obu, tzn. Jest singletonem podobnym do obiektu i z dużą ilością płyty kotłowej, jak w przypadku klasy spraw. Jedyna różnica polega na tym, że płyta kotłowa jest wykonywana dla obiektu zamiast klasy.

obiekty case nie będą dostarczane z następującymi:

Zastosuj, Cofnij metody. tutaj nie ma metod kopiowania, ponieważ jest to singleton. Brak metody porównania równości strukturalnej. Nie ma też konstruktora.

— jeevan kishore
źródło