Je rencontre un problème étrange à Scala. Voici mon code, l'employé de la classe étend la personne de classe
mais ce morceau de code ne peut pas être compilé, j'ai explicitement défini le prénom et le nom de nom comme Val variable. Pourquoi donc ? Cela signifie-t-il que je dois remplacer Val variable dans la classe de base? Et quel est le but?
4 Réponses :
sauf si j'ai mal compris votre intention, voici comment prolonger personne code>. Welcome to Scala version 2.8.0.final (Java HotSpot(TM) Client VM, Java 1.6.0_21).
Type in expressions to have them evaluated.
Type :help for more information.
scala> class Person( firstName: String, lastName: String)
defined class Person
scala> class Employee(firstName: String, lastName: String, depart: String) extends Person(firstName, lastName)
defined class Employee
Étant donné que les arguments du constructeur n'ont aucune déclaration Val / Var en personne et que la personne n'est pas une classe de cas, les arguments ne seront pas membres de la personne de classe, simplement des arguments du constructeur. Le compilateur vous dit essentiellement: Hé, vous avez dit que ce prénom et un nom de famille sont membres qui remplacent / redéfinir quelque chose hérité d'une classe de base - mais il n'ya rien aussi loin que je puisse dire ...
class Person(val firstName: String, val lastName: String) class Employee(fn: String, ln: String, val salary: BigDecimal) extends Person(fn, ln)
Les paramètres d'entrée du constructeur ne sont pas des vals que si vous dites qu'ils sont. Et s'ils sont déjà, pourquoi les remplacer?
class Person(firstName: String, lastName: String) {}
class Employee(
val firstName: String, val lastName: String, val depart: String
) extends Person(firstName,lastName) {}
Cette réponse répond à la question avec une question. Que je vais essayer de répondre. La raison pour laquelle vous devez dire remplacer devant val dans la classe étrange est de dire au compilateur que vous n'avez pas l'intention de présenter un nouveau champ. Supprimer signifie grossièrement "Ici, je déclare quelque chose qui est déjà déclaré dans la classe mère et n'a pas l'intention d'introduire quelque chose qui n'est pas hérité". Sans le "remplacement" val signifie "créer un champ public, loadonly". Cependant, SCALA ne permet pas à deux champs VAL d'avoir le même nom. Ainsi, le remplacent est obligatoire.
@Theodorenorvell - Mon point était censé être qu'il y a aucune raison pour créer le remplacement si vous allez simplement étendre la classe d'origine avec les mêmes champs. Il suffit de les transmettre en tant que paramètres et laissez les vals de superclasse être des vals.
@Rexkerr ok, c'est un bon point. Vous demandiez: "Pourquoi avoir le remplacer Val ?"; Je répondais, "pourquoi avoir le remplacer étant donné que vous avez le val ?". Dans le code que j'écris, j'ai eu une situation similaire, mais dans mon cas, la sous-classe est une classe de cas et que le paramètre Constructor est donc automatiquement un Val. Dans ce cas, le compilateur donne un message d'erreur à moins que le mot clé est là et, vraisemblablement pour des raisons syntaxiques, il nécessite également le mot-clé val . Les seuls inconvénients sont ces deux mots supplémentaires et que le champ est initialisé deux fois.
@Theodorenorvell - Assez juste - Les classes de cas sont une raison de l'utiliser.
Comme je l'ai mentionné, j'ai eu une classe de cas. Essentiellement, j'ai eu Commande de classe abstraite scellée (Val Coord: Coord); Affectation de la classe de cas (LHS: EXPR, RHS: EXPR, Supprimer Val Coord: Coord) prolonge la commande (coord); ... et ensuite de nombreux autres cas. Un meilleur moyen de le faire était de donner aux constructeurs 2 listes de paramètres comme ceci: Commande de classe abstraite scellée (VAL COOD: COOD); Affectation de la classe de cas (LHS: EXPR, RHS: EXPR) (Coord: Coord) étend la commande (coord); ... . Dans la liste des 2e paramètres, les paramètres ne sont pas automatiquement fabriqués dans les champs val .
Vous pourriez également envisager de redéfinir vos superches de superbes classes comme des traits autant que possible. Exemple: ou même