Différence entre l'objet de cas et l'objet

226

Y a-t-il une différence entre un objet et un objet dans scala?

scala

3

Il a un point - il n'est pas nécessaire d'avoir un objet case pour pouvoir faire correspondre un motif dessus. Je pense que cela n'a pas été abordé dans la question précédente ...

— axel22

3

Je pensais qu'il y aurait une différence dans le comportement de correspondance de motifs, mais un objet cas et un objet normal se comportent de la même manière dans une correspondance de motifs AFAIK. Il est assez difficile de trouver des informations sur les objets de cas, donc j'ai hâte que quelqu'un nous éclaire.

— Âge Mooij

4

Il n'est pas nécessaire d'utiliser casepour avoir une correspondance de modèle, c'est juste du sucre. Vous mettre en œuvre unapplyfait le travail.

— Raphael

1

La réponse acceptée ne répond tout simplement pas à la question, comme discuté dans les commentaires à ce sujet. Trop tard pour faire la différence, mais il faut le noter.

— itsbruce

Il n'est pas trop tard pour modifier la réponse acceptée. La modification sera examinée et, le cas échéant, acceptée.

— C4stor

111

Les classes de cas diffèrent des classes ordinaires en ce sens qu'elles obtiennent:

support de correspondance de motifs
implémentations par défaut de equalsethashCode
implémentations par défaut de la sérialisation
une implémentation par défaut plus jolie de toString, et
la petite quantité de fonctionnalités dont ils bénéficient en héritant automatiquement scala.Product.

La mise en correspondance de modèles, l'égal et le hashCode n'ont pas beaucoup d'importance pour les singletons (à moins que vous ne fassiez quelque chose de vraiment dégénéré), vous obtenez donc à peu près la sérialisation, une belle toStringet certaines méthodes que vous n'utiliserez probablement jamais.

— Dave Griffith
source

46

Les points 3 et 4 de cette réponse sont une différence correcte entre les objets de cas et les objets. Les points 1 et 2 n'ont pas d'importance pour les objets singleton. Et les objets singleton sont toujours des produits avec une arité 0, donc le point 5 n'a pas d'importance non plus.

— Wojciech Durczyński

86

Ce message perpétue le mythe qui objectest le même qu'un singleton. Ce n'est pas. C'est plutôt exactement ce qu'il dit qu'il est, un objet, c'est-à-dire une déclaration et une instanciation en un. Cela se limite objectà une seule instance si elle est définie dans la portée du package, ce qui en fait un singleton, mais uniquement si elle est définie DANS CETTE PORTÉE. Si défini dans une classe, vous pouvez avoir autant d'instances que la classe elle-même (elle est instanciée paresseusement, donc ce n'est pas nécessairement 1-1). Et ces objets internes peuvent très bien être utilisés comme clés de hachage, ce qui rend très égal par défaut / hashCode.

— nilskp

66

La question case objectne concerne pas la classe, pourquoi est-ce la bonne réponse?

— Ixx

10

Cela ne répond pas à la question. Cette réponse traite de la différence entre case classet a class. La question porte sur la différence entre case objectet object.

— MK

6

@ C4stor La réponse ne dit pas cela, cependant. Un objet n'est pas une classe. Étant donné que les classes de cas font beaucoup de magie dans les coulisses, compte tenu des divers cas et complications de Scala, il n'y a aucune raison de simplement supposer que la seule différence entre un objet Scala standard et un objet de cas s'explique par ce que nous savons de la différence. entre les classes standard et les classes de cas. Cette réponse ne répond même pas au libellé de la question.

— itsbruce

137

Voici une différence - les objets cas étendent le Serializabletrait, afin qu'ils puissent être sérialisés. Les objets normaux ne peuvent pas par défaut:

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
source

15

Je pense que les objets de cas peuvent être sérialisés est la plus grande différence par rapport aux objets réguliers, en particulier dans la communication réseau entre les acteurs

— 爱国者

14

L'ajout extends Serializabledevrait faire la même chose.

— nilskp

36

scala> object foo

objet défini foo

scala> case object foocase

objet défini foocase

Différence de sérialisation:

scala> foo.asInstanceOf[Serializable]

java.lang.ClassCastException: foo $ ne peut pas être converti en scala.Serializable
... 43 élidé

scala> foocase.asInstanceOf[Serializable]

res1: Sérialisable = foocase

Différence toString:

scala> foo

res2: foo.type = foo $ @ 7bf0bac8

scala> foocase

res3: foocase.type = foocase

— Minnie
source

2

Les objets case sont implicitement fournis avec les implémentations des méthodes toString, equals et hashCode, mais pas les objets simples. les objets de cas peuvent être sérialisés alors que les objets simples ne le peuvent pas, ce qui rend les objets de cas très utiles comme messages avec Akka-Remote. L'ajout du mot clé case avant le mot clé object rend l'objet sérialisable.

— Prashant_Sharma
source

0

C'est similaire avec case classet class, nous utilisons juste case objectau lieu de case classquand il n'y a pas de champs représentant des informations d'état supplémentaires.

— route des vins
source

0

Nous connaissons les objets et la "classe de cas" auparavant. Mais "objet de cas" est un mélange des deux, c'est-à-dire qu'il s'agit d'un singleton similaire à un objet et avec beaucoup de passe-partout comme dans une classe de cas. La seule différence est que le passe-partout est fait pour un objet au lieu d'une classe.

les objets de cas ne viendront pas avec ceux ci-dessous:

Appliquer, désappliquer les méthodes. il n'y a pas de méthodes de copie puisqu'il s'agit d'un singleton. Aucune méthode de comparaison de l'égalité structurelle. Pas de constructeur aussi.

— jeevan kishore
source