2010-10-03 3 views
1

Considérons les modèles d'architecture d'application d'entreprise de Martin Fowler et le modèle de contrôleur frontal: http://martinfowler.com/eaaCatalog/frontController.html Apparemment, il utilise le modèle singleton. Eh bien, j'ai un paquet de classes dans l'application php qui fonctionnent ensemble (comme le paquetage Controller de Zend) et il y a une classe qui les rend tous utilisables et comme elle ressemble beaucoup aux concepts de Front Controller, je l'ai nommé PackageName_Front. Mais ce ne devrait pas être une classe singleton (par opposition à Front Controller), alors est-ce que je le laisse toujours avoir le nom Front? Sinon, qu'est-ce que je le nomme? Comme c'est un paquet assez gros, j'ai juste besoin de suivre les conventions autant que possible (pas de manière dogmatique!) Afin qu'il soit lisible par d'autres développeurs.Est-ce que toutes les classes avant doivent utiliser singleton?

Plus d'info: 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. Cela doit être PackageName_Something, et je ne suis juste pas le père de Quelque chose devrait être. Peut-être que "Handler"? ... Je veux juste m'assurer que quand quelqu'un lit son nom, il ne s'embarrasse pas de son rôle dans l'ensemble du paquet :)

+1

Le modèle tel que décrit en ligne ne semble pas impliquer quelque chose à propos de Singleton, à moins que je ne comprenne mal l'UML. – cHao

Répondre

1

Apparemment, il [FrontController] utilise le modèle singleton.

FrontController ne doit pas être implémenté en tant que Singleton. Le livre ne suggère rien de tel. L'exemple du livre utilise une servlet pour le gestionnaire.

Juste parce qu'une classe ne sera nécessaire qu'une fois dans une application ne justifie pas son implémentation en tant que singleton.Il manque le but du Singleton qui est de d'appliquer une classe ne peut avoir qu'une seule instance et fournir un accès global à elle. Si vous avez besoin d'une instance particulière une seule fois, pensez plutôt à Just Create One. Beaucoup de gens de nos jours (y compris Erich Gamma de la renommée du GoF) considèrent le Singleton comme une odeur de code et découragent son utilisation. Dans une architecture shared-nothing, Singleton ne peut que limiter les instances de la requête en cours, donc l'utilisation de PHP est limitée. L'accès global à un objet peut être réalisé sans le modèle Singleton, que ce soit par le biais du mot clé global (mal) ou des méthodes statiques. L'accès global crée toujours un couplage inutile. Le meilleur moyen serait d'utiliser l'injection de dépendances, qui a l'avantage supplémentaire de fournir moins de couplage et donc une meilleure maintenabilité. Est-ce que je l'ai quand même laissé le nom Front?

Sinon, qu'est-ce que je le nomme? Comme il est un paquet assez grand, j'ai juste besoin de suivre les conventions autant que possible (pas de manière dogmatique!)

Il n'y a pas de convention sur les classes nommant avant cours à ma connaissance. Ce que vous décrivez pourrait être un Facade ou un Gateway cependant. En outre, êtes-vous sûr que vous ne pouvez pas nommer la classe après le nom de package? Après tout, le paquet Zend_Form a aussi une classe Zend_Form.

+0

Je ne sais pas pourquoi je ne le nommerais pas PackageName! Je ne sais pas, ça ne sonne juste pas bien! J'ai beaucoup d'autres paquets nommés après leur nom de paquet et ils ont l'air bien! Mais dans ce cas, ... Je ne sais pas: D –

+0

@CgAlive bien, nommez-le après ce qu'il fait. Si vous pensez que Front est un bon nom, nommez-le avant. Personnellement, je ne trouve pas cela aussi descriptif, mais en l'absence d'un meilleur nom, faites-le. – Gordon

+0

Ouais j'ai utilisé Front et je pense que ça sonne un peu juste jusqu'à maintenant! Sa fonctionnalité ressemble à un "Front"! :"RÉ –

0

L'idée derrière le motif singleton est de s'assurer qu'il n'y a que une instance d'un objet supposé n'exister que dans une instance unique. Le contrôleur frontal tombe très bien dans cette catégorie, il serait donc peut-être sage de le faire suivre un modèle singleton. Cependant, si votre code veille toujours à ce qu'il appelle le constructeur une seule fois, alors il y a de la place pour votre objet pattern non singleton.

Mes 2 cents ici, puisque je ne suis pas un auteur de livres ou quelque chose.

+0

Euh, j'ai ajouté quelques informations à ma question :) –

1

Juste d'une vision purement design, il semble que vous utilisez ce PackageName_Front comme une façade quand vous dites:

il y a une classe qui les rend utilisables

Fowler l'implémentation du modèle indique:

Le contrôleur frontal consolide toutes les demandes en canalisant demandes par l'intermédiaire d'un seul gestionnaire objet

Ce insinue que Singleton pourrait être utilisé pour mettre en œuvre la classe Front Controller, mais il ne doute pas contraignent à l'utiliser. Il ne le mentionne pas explicitement cependant.

Je ne pense pas que ce soit important de savoir si c'est un Singleton. S'assure juste que c'est le canal unique pour les demandes, et vous aurez utilisé avec succès le modèle. :)

+0

Je vais mettre à jour ma question :) –

Questions connexes