Je commence Scala. Suis-je correct la compréhension que je devrais définir une classe comme classe de cas si j'aimerais que ce soit des arguments d'être exposés comme propriétés? Ne présente-t-il pas d'effets secondaires?
4 Réponses :
Vous obtiendrez des corrections pour tous les paramètres définis et ils seront des vals (c.-à-d. des finales) Vous pouvez également obtenir ce comportement avec des classes régulières (c.-à-d. des classes non cas) également: p> // creates two final public properties as well
class User(val name: String, val group: String)
// creates read/write public properties
class User(var name: String, var group: String)
val user = new User("jsmith", "admins")
user.group = "guests"
Merci. Mais existe-t-il des effets secondaires qui peuvent causer un comportement inattendu (menant à des insectes alors)? Pourquoi utiliserait-on des classes non cas dans des cas habituels?
Le code de la chaudron généré pour les classes de boîtier porte un coût petit mais non nul en bytecode. En plus de la méthode COPY , il y a Plus significatif est le fait qu'il est invisible de dériver des cours des classes de cas. Dériver une classe de cas d'une classe de cas invite réellement des problèmes (et le compilateur vous criera). En particulier, aucune méthode de copie inférieure Si vous gardez vos cours de cas aux feuilles de tout graphique d'héritage, tout ira bien. hashcode , est égal à et tostring ainsi que la méthode d'usine d'objet compagnon .
(...) est générée par le compilateur, de sorte que vous puissiez obtenir des modes de défaillance impairs si vous essayez de copier une classe de cas dérivée d'une classe de cas.
En plus des points déjà mentionnés, une classe de cas est conceptuellement près de ce que vous appelez une "classe de valeur" dans Java. Bien sûr, rien ne vous empêche d'écrire des classes de cas mutables ou des classes de cas avec une fonctionnalité lourde, mais peu de données, mais cela pourrait surprendre les autres travaillant avec votre code. En règle générale, je dirais au moins réfléchir à deux fois avant de créer des classes de cas ...
Pourriez-vous s'il vous plaît expliquer pourquoi éviter les classes de cas lorsque la performance est vraiment importante?
1) Les classes de cas doivent faire un peu plus de travail sur la construction. 2) Les implémentations de ##, équivalent, la totring, etc. doivent être assez élaborées pour éviter les problèmes dans les cas «edgy», afin que vous puissiez probablement économiser quelques ops en les mettant en œuvre vous-même. Notez que je parle de différences de performance minimes qui peuvent compter sur des vecteurs et des matrices pour les graphiques 3D, mais pas pour les applications «normales».
Les autres réponses sont toutes bien, mais le seul risque réel qui manquent est que les classes de cas ont une égalité de valeur, ce qui se comporte très différemment de l'égalité d'identité standard orientée objet. Deux objets de cas sont égaux si tous leurs champs sont égaux. C'est exactement ce qui est nécessaire dans certains cas, mais très inattendu dans d'autres. En particulier, l'ajout d'un état mutable à quelque chose avec l'égalité de la valeur est de demander des problèmes. Vous pouvez facilement vous retrouver avec des objets dont le hashcode change avec le temps, ce qui entraîne des hachons corrompus et une autre nezsitude aussi.
Déclarant quelque chose d'une classe de cas afin de sauvegarder quelques coups de frappe déclarant que "Val" est une fausse économie et un jour vous mordre un jour.