2016-04-13 2 views
0

Certaines bibliothèques open source like twitters semblent avoir une convention pour marquer les classes de cas final.Quels sont les avantages pratiques du marquage des classes de cas en tant que final dans scala

Mon équipe décide de l'adoption de cette convention, mais nous ne comprenons pas encore les avantages de cela. Actuellement, le seul avantage possible que je peux percevoir est qu'il arrête l'héritage accidentel des classes de cas.

Mais y a-t-il d'autres avantages? Est-ce que cela améliore les temps de compilation ou permet au compilateur d'ajouter des optimisations internes? J'espérais que cela aiderait à détecter les valeurs manquantes dans les correspondances de modèles, mais cela ne semble pas non plus le cas. Dans un script simple comme celui-ci, le compilateur génère un avertissement pour matchSealed mais pas pour matchFinal:

sealed case class Sealed(one: Option[Int], two: Option[Int]) 

def matchSealed(s: Sealed): Unit = s match { 
    case Sealed(Some(i), None) => println(i) 
} 

final case class Final(one: Option[Int], two: Option[Int]) 

def matchFinal(f: Final): Unit = f match { 
    case Final(Some(i), None) => println(i) 
} 

Mon impression de final est qu'il est une restriction plus forte que sealed, il est donc étrange que cela ne génère pas d'avertissement .

+0

[Cet article] (http://underscore.io/blog/posts/2015/06/02/everything-about-sealed.html) parle de ce problème dans ses commentaires de clôture. L'auteur utilise 'final' en disant que c'est plus descriptif, c'est une convention et cela ouvre des possibilités pour les optimisations du compilateur (bien qu'on n'en connaisse aucune). – rmin

Répondre

0

Voici an explanation of some benefits:

Une classe de cas finale ne peut être prolongée par une autre classe. Cela signifie que vous pouvez faire des garanties plus fortes sur la façon dont votre code se comporte. Vous savez que personne ne peut sous-classer votre classe, remplacer certaines méthodes et faire quelque chose d'idiot. C'est génial quand vous déboguez du code - vous n'avez pas besoin d'aller chercher partout dans la hiérarchie des objets pour déterminer quelles méthodes sont réellement appelées.

Bien sûr, rendre les classes finales signifie que vous perdez une forme d'extensibilité. Si vous souhaitez autoriser les utilisateurs à implémenter des fonctionnalités, vous devez intégrer cette fonctionnalité dans un trait et utiliser le modèle de classe de type à la place.

+0

Merci @marcospereira. Donc, il semble que cela arrête juste l'héritage. Pour nous, ce n'est pas une grande victoire parce que nous n'essayons pas d'étendre les classes de cas de toute façon. J'espère qu'il y a d'autres avantages. – rmin