Quels sont les avantages des objets compagnons de Scala par rapport aux méthodes statiques?

Scala n'a pas de mot clé statique , mais a des fonctionnalités similaires via des objets compagnons. En coulisse, les objets compagnon sont compilés en classes qui ont des méthodes statiques, donc tout ceci est du sucre syntaxique. Quels sont les avantages de ce choix de design? Désavantages? Est-ce que d'autres langues ont des constructions similaires?

Voici quelques raisons qui pourraient être plus ou moins convaincantes pour vous, selon vos propres préférences:

1. Ne le négligez pas pour le qualifier de "sucre syntaxique". Bien que vous puissiez dire que quelque chose n'est que du sucre syntaxique, c'est après tout le sucre qui adoucit votre vie - en tant que programmeur tout autant qu'un buveur de café ou de thé.

2. Singletons - chaque Scala objectest intrinsèquement un singleton. Étant donné que dans le monde Java, les personnes implémentent des singletons de différentes manières et finissent souvent par commettre une erreur dans leur implémentation, vous ne pouvez pas commettre une erreur aussi simple que celle dans Scala. Ecrire objectau lieu d'en classfaire un singleton et vous avez terminé.

3. Accès aux méthodes statiques: Les méthodes statiques en Java sont accessibles à partir d’objets. Par exemple, supposons que vous ayez une classe Cavec une méthode statique fet un objet cde type C. Ensuite, vous devriez appeler C.f, mais Java vous permet (avec un avertissement) d’utiliser c.f, ce qui, quand vous venez de l’arrière-plan Scala, n’a aucun sens, car les objets n’ont pas fvraiment de méthode .

4. Séparation claire: En Java, vous pouvez mélanger des attributs et des méthodes statiques et non statiques dans une classe. Si vous travaillez avec discipline, cela ne deviendra pas un problème, cependant, si vous (ou quelqu'un d'autre d'ailleurs) ne le faites pas, vous vous retrouverez avec des parties statiques et non statiques entrelacées et il est difficile de dire en un coup d'œil Qu'est-ce qui est statique et ce qui ne l'est pas? Dans Scala, tout ce qui se trouve dans l'objet compagnon ne fait clairement pas partie des objets d'exécution de la classe correspondante, mais est disponible à partir d'un contexte statique. Inversement, s'il est écrit dans une classe, il est disponible pour les instances de cette classe, mais pas à partir d'un contexte statique. Cela devient particulièrement lourd en Java, une fois que vous avez commencé à ajouter des blocs d'initialisation statiques et non statiques à votre classe. Cela peut être très difficile à comprendre en termes d’ordre d’exécution dynamique.

5. Moins de code: vous n'avez pas besoin d'ajouter le mot statique à chaque attribut ou méthode dans un object, ce qui permet de garder le code plus concis (ce n'est pas vraiment un avantage important).

Les inconvénients sont beaucoup plus difficiles à trouver. On pourrait faire valoir que les parties statiques et non statiques doivent appartenir ensemble, mais sont séparées par le concept Scala d’objets compagnons. Par exemple, il peut sembler étrange d’avoir un diagramme de classes, mais finit par devoir créer deux choses dans le code et disséquer l’attribut qui va où.

Un autre avantage est que objects peut implémenter des interfaces / traits, contrairement aux méthodes statiques.

Les objets compagnons sont les premiers objets recherchés, après quoi scala examine Predef, puis dans des instructions "d'importation" explicites dans ce fichier source particulier.

Je ne suis pas assez d'un développeur Java pour savoir si le langage Java ou les bibliothèques fournissent un mécanisme comparable.