Pourquoi Scala n'a-t-il pas de membres statiques à l'intérieur d'une classe ?

Question

Je sais que tu peux les définir indirectement réaliser quelque chose de similaire avec les objets compagnons, mais je me demande pourquoi la statique a été supprimée des définitions de classes dans la conception du langage.

Answer 1

Le O dans OO signifie "Object", pas "class". L'orientation objet concerne les objets, ou les instances (si vous préférez).

Les statiques n'appartiennent pas à un objet, ils ne peuvent pas être hérités, ils ne participent pas au polymorphisme. Pour faire simple, les statiques ne sont pas orientées objet.

Scala, d'autre part, est orienté objet. Bien plus que Java, qui s'est efforcé de se comporter comme le C++, afin d'attirer les développeurs de ce langage.

Ils sont un hack, inventé par le C++, qui cherchait à jeter un pont entre les mondes de la programmation procédurale et OO, et qui devait être rétrocompatible avec le C. Il a également admis les primitives pour des raisons similaires.

Scala laisse tomber les statiques et les primitives parce qu'elles sont une relique d'une époque où les développeurs ex-procéduraux avaient besoin d'être apaisés. Ces choses n'ont pas leur place dans un langage bien conçu qui souhaite se décrire comme orienté objet.

---

Concernant pourquoi il est important d'être vraiment OO, je vais copier et coller sans vergogne ce passage de Bill Venners sur la liste de diffusion :

La façon dont je vois les choses, cependant, c'est que les objets singleton vous permettent de de faire les choses statiques là où elles sont nécessaires de manière très concise, mais mais aussi de bénéficier de l'héritage quand vous en avez besoin. Un exemple est plus facile de tester les parties statiques de votre programme, parce que vous pouvez faire traits qui modélisent ces parties et utiliser ces traits partout. Ensuite, dans programme de production, utilisez une implémentation d'objet unique de ces traits traits, mais dans les tests, utilisez des instances fantaisie.

Je n'aurais pas pu mieux dire !

Ainsi, si vous voulez créer un seul exemplaire de quelque chose, les statiques et les singletons peuvent faire l'affaire. Mais si vous voulez que cette seule chose hérite du comportement d'un autre élément, alors les statiques ne vous aideront pas.

D'après mon expérience, vous avez tendance à utiliser cette capacité bien plus souvent que vous ne l'auriez pensé au départ, surtout après avoir utilisé Scala pendant un certain temps.

Answer 2

J'ai également posté cette question sur le groupe google des utilisateurs de scala et Bill Venners, l'un des auteurs de "Programming in scala", a répondu en donnant quelques idées.

Jetez un coup d'oeil à ça : https://groups.google.com/d/msg/scala-user/5jZZrJADbsc/6vZJgi42TIMJ et https://groups.google.com/d/msg/scala-user/5jZZrJADbsc/oTrLFtwGjpEJ

En voici un extrait :

Je pense qu'un était simplement d'être plus simple, en faisant en sorte que chaque valeur soit un objet, et chaque opération un appel de méthode. Les statiques et les primitives de Java sont cas spéciaux, ce qui rend le langage plus "compliqué" dans un certain sens. sens.

Mais un autre élément important, je pense, est d'avoir quelque chose que l'on peut mettre en correspondance avec la méthode Java de Java en Scala (parce que Scala avait besoin d'une construction qui correspondait aux statiques de Java pour l'interopérabilité), mais qui bénéficie de l'héritage/polymorphisme OO héritage/polymorphisme. Les objets singletons sont de vrais objets. Ils peuvent Ils peuvent étendre une superclasse ou intégrer des traits et être transmis en tant que tels. Pourtant, ils sont également "statiques" par nature. Cela s'avère très pratique dans la pratique.

Jetez également un coup d'œil à cet entretien avec Martin Odersky (faites défiler la page jusqu'à la section Innovations orientées objet dans Scala). http://www.artima.com/scalazine/articles/goals_of_scala.html

En voici un extrait :

Tout d'abord, nous voulions être un langage purement orienté objet, où chaque valeur est un objet, chaque opération est un appel de méthode et chaque variable est un membre d'un objet. Nous ne voulions donc pas de statiques, mais nous avions besoin de quelque chose pour les remplacer, nous avons donc créé la construction d'objets singletons. Mais même les objets singleton sont toujours des structures globales. Le défi était donc de les utiliser le moins possible, car lorsque vous avez une structure globale, vous ne pouvez plus la modifier. Vous ne pouvez pas l'instancier. Il est très difficile de la tester. Il est très difficile de la modifier de quelque manière que ce soit.

Pour résumer :

D'un point de vue de la programmation fonctionnelle, les membres statiques sont généralement considérés comme mauvais (voir ceci poste par Gilad Bracha - le père des génériques java. Il s'agit principalement d'effets secondaires dus à l'état global). Mais Scala devait trouver un moyen d'être interopérable avec Java (il devait donc supporter les statiques) et pour minimiser (mais pas totalement éviter) les états globaux qui sont créés à cause des statiques, Scala a décidé de les isoler dans des objets compagnons.

Les objets compagnons ont également l'avantage d'être extensibles, c'est-à-dire de tirer parti de l'héritage et de la composition de mixins (indépendamment de l'émulation de fonctionnalités statiques pour l'interopérabilité).

Answer 3

Ce sont les choses qui me viennent à l'esprit quand je pense à la façon dont les statiques pourraient compliquer les choses :

1) L'héritage ainsi que le polymorphisme nécessiteraient des règles spéciales. Voici un exemple :

// This is Java
public class A {
  public static int f() {
    return 10;
  }
}

public class B extends A {
  public static int f() {
    return 5;
  }
}

public class Main {
  public static void main(String[] args) {
    A a = new A();
    System.out.println(a.f());
    B b = new B();
    System.out.println(b.f());
    A ba = new B();
    System.out.println(ba.f());
   }
}

Si vous êtes sûr à 100% de ce qui est imprimé, tant mieux pour vous. Le reste d'entre nous peut se fier à des outils puissants tels que @Override qui est bien sûr facultative et l'annotation amicale "La méthode statique f() du type A doit être accédée de manière statique". avertissement. Cela nous amène à

2) La "manière statique" d'accéder aux éléments est une autre règle spéciale, qui complique les choses.

3) Les membres statiques ne peuvent pas être abstraits. Je suppose que l'on ne peut pas tout avoir, n'est-ce pas ?

Et encore, ce ne sont que des choses qui me sont venues à l'esprit après avoir réfléchi à la question pendant quelques minutes. Je parie qu'il y a un tas d'autres raisons pour lesquelles la statique ne s'intègre pas dans le paradigme OO.

Answer 4

C'est vrai, les membres statiques n'existent pas, MAIS, il est possible d'associer un objet singleton à chaque classe :

class MyClass {
}

object MyClass {
}

pour obtenir des résultats similaires

Answer 5

La programmation orientée objet concerne les objets et leurs états (sans toucher aux objets à état complet et sans état en Java). J'essaie de souligner "Le statique n'appartient pas aux objets". Les champs statiques ne peuvent pas être utilisés pour représenter l'état d'un objet. donc il est rationnel de le retirer des objets.