Tous les classes de front devraient-elles utiliser Singleton?

Question

Considérez les modèles d'architecture d'application d'entreprise de Martin Fowler et le modèle de contrôleur avant: http://martinfowler.com/eaacatalog/frontcontroller.htmlApparemment, il utilise le modèle singleton. Eh bien, j'ai un paquet de classes dans l'application PHP qui fonctionnent ensemble (comme le package de contrôleur de Zend) et il y a une classe qui les rend toutes utilisables et comme elle ressemble à une grande partie des concepts du contrôleur avant, je l'ai nommé packageName_Front. Mais ce ne devrait pas être une classe singleton (par opposition au contrôleur avant), alors est-ce que je le laisse toujours avoir le nom? Sinon, comment dois-je le nommer? Comme c'est un package assez important, j'en ai juste besoin pour suivre autant que possible les conventions (pas de manière dogmatique!) Il serait donc lisible pour d'autres développeurs.

Plus d'informations: ce n'est rien lié aux contrôleurs. C'est juste un objet qui fonctionne comme Zend_Form (qui consolide l'utilisation de tous les autres objets comme zend_form_element_x et zend_validate en un seul objet) mais je ne peux pas simplement le nommer packageName. Il doit s'agir de packagename_something, et je ne suis tout simplement pas à ce que devrait être quelque chose. Peut-être que "Handler"? ... Je veux juste m'assurer que quand quelqu'un lit son nom, il n'est pas confus à propos de son rôle dans tout le package :)

Answer 1

Apparemment, ça FrontController utilise le singleton motif.

FrontController n'a pas à être mis en œuvre sous le nom de Singleton. Le livre ne suggère rien de tel. L'exemple du livre utilise un servlet pour le gestionnaire.

Ce n'est pas parce qu'une classe ne sera nécessaire que dans une application ne justifie pas son implémentation en tant que singleton. Il manque le but du singleton qui est de imposer Une classe ne peut avoir qu'une seule instance et fournir un accès global à lui. Si vous n'avez besoin d'une instance particulière qu'une seule fois, considérez Créez-en un Au lieu.

Beaucoup de gens de nos jours (y compris Erich Gamma de la renommée GoF) considèrent le singleton comme une odeur de code et de décourager son utilisation. Dans une architecture partagée, le singleton ne peut que restreindre les instances à l'intérieur de la demande actuelle de toute façon, donc l'utilisation en PHP est limitée. L'accès global à un objet peut être atteint sans le modèle Singleton, soit par le mot-clé global (maléfique), soit par des méthodes statiques. L'accès global crée toujours un couplage inutile. La meilleure façon serait d'utiliser l'injection de dépendance, qui a l'avantage supplémentaire de fournir moins de couplage et donc une meilleure maintenabilité.

Alors est-ce que je le laisse toujours avoir le nom avant? Sinon, comment dois-je le nommer? Comme c'est un package assez important, j'en ai juste besoin pour suivre autant que possible les conventions (pas de manière dogmatique!)

Il n'y a pas une telle convention sur le nom des cours De face cours à ma connaissance. Ce que vous décrivez pourrait être un Façade ou un passerelle pourtant. De plus, êtes-vous sûr de ne pas ne pas nommer la classe après le packagename? Après tout, le Zend_Form Le package a un Zend_Form classe aussi.

Answer 2

Juste d'une vue purement de conception, il semble que vous utilisiez ce packagename_front comme une façade lorsque vous dites:

Il y a une classe qui les rend tous utilisables

La mise en œuvre du modèle par Fowler dit:

Le contrôleur avant consolide toutes les demandes de manipulation en canalisant les demandes via un seul objet de gestionnaire

Cela insinue qu'un singleton pourrait être utilisé pour implémenter la classe de contrôleur avant, mais il ne le contraint certainement pas pour l'utiliser. Il ne le mentionne pas explicitement.

Je ne pense pas qu'il soit important que ce soit ou non un singleton. S'assure simplement que c'est le seul canal pour les demandes, et vous aurez utilisé avec succès le modèle. :)

Answer 3

L'idée derrière le singleton est de s'assurer qu'il n'y a qu'une seule instance d'un objet qui n'est censé exister que dans une seule instance. Le contrôleur avant tombe très bien dans cette catégorie, il serait donc peut-être sage de le faire suivre un singleton.

Si, cependant, votre code s'assurera toujours qu'il n'appelle le constructeur qu'une seule fois, il y a de la place pour votre objet de motif non-Singleton.

Mes 2 cents ici, car je ne suis pas un auteur de livres ou quelque chose comme ça.