Le cadre de Play ! utilise un <lot>de statique

Question

Waaah, le framework Play ! a tellement de méthodes statiques. Là où je vais à l'école, on nous disait jamais, jamais d'utiliser de la statique, mais Play ! l'utilise comme s'il n'y avait pas de lendemain. Est-ce que cela est acceptable ? Si oui, pourquoi ?

Nous (7 personnes et moi) prévoyons d'utiliser le framework Play ! pour un projet impliquant une application web. Nous avons décidé de le faire avec Play ! parce qu'il a l'air assez amusant à faire, que nous connaissons tous déjà Java et que la mission est assez difficile. Nous voulions donc nous concentrer sur la mission elle-même plutôt que d'apprendre à programmer dans un autre langage.

On nous a toujours dit, cependant, JAMAIS JAMAIS d'utiliser des "statics" dans tous les programmes Java que nous développions, mais quand je regarde Play ! ... Eh bien ... environ la moitié des méthodes sont statiques. </exaggeration>

Je suppose qu'au minimum, nous pourrions utiliser des objets singletons (en utilisant Scala, par exemple ^^) afin de programmer notre projet, mais je suis assez préoccupé par le nombre de statiques qu'il y a réellement dans le framework lui-même.

Alors, dois-je m'en inquiéter ? La façon dont les développeurs de Play ! l'ont programmé a-t-elle fait en sorte que toutes ces statiques ne posent pas de problème ?

(Par exemple, ce fil a un discours sur les raisons pour lesquelles les membres statiques doivent être évités à tout prix).

Answer 1

Play n'utilise les méthodes statiques que lorsque cela a un sens :

• dans la couche contrôleur, car les contrôleurs ne sont pas orientés objet. Les contrôleurs agissent comme un mappeur entre le monde HTTP (qui est sans état et basé sur des demandes/réponses) et la couche Modèle qui est entièrement orientée objet.
• dans la couche modèle pour les méthodes d'usine, comme findAll(), count(), create() qui, bien sûr, ne dépendent d'aucune instance particulière.
• dans certaines classes play.libs.* qui fournit des fonctions purement utilitaires

Answer 2

Le cadre de jeu n'est pas une bonne démonstration de l'opportunité d'utiliser la statique, et il ne prouve pas non plus que votre professeur avait tort. Play est une sorte de tricherie, qui résout les problèmes de statique en dehors du langage Java.

Le principal problème est que vous devez traiter plusieurs requêtes HTTP en parallèle, et que les champs statiques sont "globaux". Vous aurez donc besoin d'une instance par thread (ou mieux encore, d'une instance par requête HTTP) pour certaines choses, alors que certaines de ces choses sont renvoyées par des méthodes statiques dans Play. Cela fonctionne parce que Play ! utilise ThreadLocal -s lourdement, et résout ainsi un problème de statique en dehors du langage Java. Mais ce n'est pas tout. Certains disent que les méthodes des contrôleurs sont à juste titre statiques. C'est vrai, mais en Java, cela ne serait pas pratique, car il serait alors impossible d'accéder à des données spécifiques à une requête sans une sorte de préfixe, par exemple req. sur req.session et ensuite tu dois encore obtenir req de quelque part, comme un paramètre de la méthode du contrôleur statique, ce qui est encore plus compliqué. Pourtant, dans Play, vous pouvez simplement écrire directement session et comme, ils sont juste des champs statiques. C'est parce que Play utilise l'instrumentation du bytecode pour changer toutes ces références de champs statiques en quelque chose de plus intelligent. Encore une fois, une solution en dehors du langage Java. Ce ne sont pas des champs statiques à la fin.

Donc, en général, évitez les statiques non finales. Le jeu fait cependant la magie pour vous, alors n'ayez pas peur d'eux dans ce cas.

Answer 3

Après un bref coup d'œil, je dirais que c'est assez logique : les requêtes web sont sans état, donc il n'y a pas d'erreur. es aucun objet pour recevoir la demande (=la méthode). Ainsi, le mappage d'un URI tel que "/articles/archive?date=08/01/08&page=2" à une méthode statique appelée archive() sur, je suppose, votre classe d'application a du sens.

Answer 4

EDIT Maintenant dans Play 2.4, l'injection se fait automatiquement. Il suffit donc d'ajouter @ au début du chemin du contrôleur dans le fichier routes fera l'affaire :

GET     /                  @controllers.Application.index()

Pour les versions plus anciennes (2.1 à 2.3), vous devrez surcharger getControllerInstance dans la classe Global, comme expliqué dans la section Documentation .

Answer 5

Comme pour tout ce qui concerne la programmation, jamais, jamais n'est jamais la bonne réponse. Tout comme toujours . Il y a toujours des exceptions et la bonne réponse est toujours "ça dépend".

Il est vrai que dans l'OO pur (que j'approuve entièrement), il y a très peu de place pour la statique. Mais il est également vrai que parfois, elles ont tout simplement du sens.

L'exemple classique est celui des méthodes utilitaires. Bien sûr, ce serait mieux si nous pouvions simplement ajouter nos méthodes de type abs() en nombre entier. Mais nous ne pouvons pas ; nous sommes donc coincés avec Math.abs(int i) .

J'ai tendance à penser qu'il est tout simplement correct de rendre une méthode statique lorsqu'elle n'a rien à voir avec l'instance elle-même. Par exemple, dans une classe Person Dans le cas d'une méthode qui prend une liste de personnes et renvoie le nombre de personnes dont l'anniversaire est aujourd'hui. Peut-être que vous ne pouvez le faire que dans la classe elle-même si les données nécessaires pour effectuer le calcul sont privées (ce qu'un puriste de l'OO comprendrait ;)) mais la méthode n'a clairement aucun rapport avec une seule instance de personne.

Une autre chose est les classes internes. Vous voulez souvent les rendre statiques si vous n'avez pas besoin de la relation avec le type contenant.

Je n'ai jamais vu Jouez ! mais si vous dites que plus de 50 % de celui-ci est statique, alors je suppose qu'il a probablement été mal conçu. Ce n'est pas une exception, c'est le cas de beaucoup de frameworks. Ne vous laissez pas abattre. N'en tirez surtout aucune leçon !
Mais si ça marche, vous pouvez toujours l'utiliser.