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
Réponses:
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.
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>caseobject B
defined module B
scala>import java.io._
import java.io._
scala>val bos =newByteArrayOutputStream
bos: java.io.ByteArrayOutputStream=
scala>val oos =newObjectOutputStream(bos)
oos: java.io.ObjectOutputStream= java.io.ObjectOutputStream@e7da60
scala> oos.writeObject(B)
scala> oos.writeObject(A)
java.io.NotSerializableException: A$
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>caseobject 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é
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.
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.
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.
casepour avoir une correspondance de modèle, c'est juste du sucre. Vous mettre en œuvreunapplyfait le travail.Réponses:
Les classes de cas diffèrent des classes ordinaires en ce sens qu'elles obtiennent:
equalsethashCodetoString, etscala.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.la source
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 limiteobjectà 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.case objectne concerne pas la classe, pourquoi est-ce la bonne réponse?case classet aclass. La question porte sur la différence entrecase objectetobject.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:la source
extends Serializabledevrait faire la même chose.Différence de sérialisation:
Différence toString:
la source
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.
la source
C'est similaire avec
case classetclass, nous utilisons justecase objectau lieu decase classquand il n'y a pas de champs représentant des informations d'état supplémentaires.la source
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.
la source