OK Les gars, je me débats pour comprendre pourquoi il y a un besoin de singleton.
Faisons un exemple réel: j'ai un cadre pour un CMS de
J'ai besoin d'une classe qui enregistre certaines informations (collez-vous sur PHP). P>
Exemple: P>
class Logger {
private static $logs = array();
public static function add($log) {
self::$logs[]=$log;
}
}
5 Réponses :
Si vous avez une méthode statique qui ouvre un fichier, écrit et ferme, vous pouvez vous retrouver avec deux appels qui tentent d'ouvrir le même fichier en même temps, car une méthode statique ne garantit pas qu'il y a une instance. .
Mais, si vous utilisez un singleton, tous les appels utilisent le même gestionnaire de fichiers. Vous n'avez donc toujours qu'une seule écriture à la fois de ce fichier.
Vous risquez de vouloir vouloir faire la queue des demandes d'écriture, au cas où il y en a plusieurs, si vous ne voulez pas qu'ils échouent, ou si vous devez vous synchroniser d'une autre manière, mais tous les appels utiliseront la même instance. < / p>
Cela peut être utile, une comparaison sur statique versus singleton, en php.
http: // moindoru .wordpress.com / 2010/03/02 / statique-call-versus-singleton-call-in-php /
Je ne pense pas que vos exemples puissent être une bonne référence à ce que je veux dire avec des objets assistant dans un cadre. Et veuillez garder à l'esprit que je fais référence à PHP où les objets statiques ne sont pas partagés entre les demandes
@ Oui123 - Peu importe si les demandes sont partagées ou non, car les pages Web sont très non déterministes, vous pouvez donc avoir plusieurs appels à la même fonction statique à la fois, et vous auriez besoin de gérer cela, si vous utilisent une ressource dans laquelle chaque appel devrait avoir un accès exclusif.
Dans PHP, il n'y a pas que le monde magique a synchronisé que vous pouvez ajouter près de la méthode pour atteindre un accès exclusif :) Donc, à la fois singleton et objet statique, subiraient le même problème de votre point de vue.
Aussi merci pour votre lien. Ce poste pointe exactement ce que je veux dire, mais ne me donne pas une réponse à ma question :) XD
@ Oui123 - Vous pouvez empêcher plus d'un appel d'aller à une fonction d'écriture journal statique en manipulant l'erreur et en attendant un peu avant de réessayer ou de détecter qu'il y a déjà quelque chose d'écriture, et encore une fois, attente. Pas idéal, mais possible, c'est pourquoi écrire dans une file d'attente et utiliser un singleton serait probablement préférable.
Plusieurs raisons.
Les méthodes statiques sont essentiellement des fonctions globales qui peuvent être appelées à partir de n'importe quelle portée, qui se prête à des bugs difficiles à suivre. Vous pourriez aussi bien utiliser une classe du tout.
Puisque vous ne pouvez pas avoir une méthode __Construction, vous devrez peut-être mettre une méthode statique init quelque part. Maintenant, les personnes dans leur code ne savent pas si la méthode init a été appelée précédemment. Est-ce qu'ils l'appellent à nouveau? Doivent-ils rechercher le codeBase pour cet appel? Et si Init était quelque part, mais est alors enlevé, ou se brise? De nombreux endroits de votre code s'appuient maintenant sur l'endroit qui appelle la méthode init.
Les méthodes statiques sont notoirement difficiles à tester un appareil avec de nombreux cadres de test unitaires.
Il y a beaucoup plus de raisons, mais il est difficile de les énumérer tous.
Les singletons ne sont pas vraiment nécessaires non plus que si vous utilisez di.
une note latérale. DI permet à vos classes de ne pas compter sur l'autre, mais plutôt des interfaces. Étant donné que leurs relations ne sont pas cimentées, il est plus facile de changer votre candidature à une heure ultérieure, et une classe de classe ne cassera pas les deux classes.
Il y a quelques cas où les classes d'état unique sont viables, par exemple, si aucune de vos méthodes ne repose sur d'autres méthodes (aucune des méthodes ne change l'état de la classe).
Cela donne certaines des raisons pour lesquelles les gens n'utilisent pas de classes statiques, pourquoi ils utilisent des singletons.
Singletons vous permet de remplacer le comportement. LOGGER :: Ajouter ('1') Par exemple peut se connecter à différents périphériques uniquement si la classe Logger sait comment. LOGGER :: getlogger () -> Ajouter ('1') peut faire différentes choses en fonction de ce que le sous-type de Logger Getlogger () retourne. Bien sûr, vous pouvez tout faire dans la classe LOGGER, mais vous finissez souvent par mettre en œuvre le singleton à l'intérieur de la classe statique.
J'utilise des singletons, je peux donc vous dire exactement pourquoi je le fais au lieu d'une fonction statique.
La définition caractéristique d'un singleton est qu'il s'agit d'une classe qui n'a qu'une seule instance. Il est facile de voir la clause "juste un cas" et d'oublier de voir la clause "C'est une classe". Après tout, c'est un objet de classe normal avec tous les avantages qui apporte. Principalement, il a son propre État et peut avoir des fonctions privées (méthodes). Les fonctions statiques doivent faire ces deux des manières plus limitées ou maladroites.
Cela dit, les deux se complètent: une fonction statique peut être levée pour renvoyer un singleton sur la même classe. C'est ce que je fais dans le singleton, j'utilise le plus souvent: un gestionnaire de base de données.
Maintenant, de nombreux programmeurs ont enseigné que "les singletons sont mauvais, MM'Kay?" Mais surpluimez le cavalier que des choses comme ne sont généralement que les mauvaises lorsqu'ils sont overutilisés . Tout comme un maître Carver, un programmeur expérimenté a beaucoup d'outils à sa disposition et beaucoup n'obtiendront pas beaucoup d'usage. Mon gestionnaire de base de données est idéal comme un singleton, mais c'est le seul que j'ai régulièrement utilisé. Pour une classe de journalisation, j'utilise habituellement des méthodes statiques.
Comme Leblonk mentionné, vous ne pouvez pas remplacer les classes statiques, ce qui rend le test de l'unité très difficile. Avec un singleton, vous pouvez instancier un objet "simulé" au lieu de la classe actuelle. Aucun changement de code nécessaire.
Les classes statiques peuvent avoir des espaces de noms de noms. Vous ne pouvez pas charger 2 classes statiques du même nom, mais vous pouvez charger 2 versions différentes d'un singleton et les instantiez sous le même nom. J'ai fait cela quand je devais tester de nouvelles versions de cours. J'instire une version différente de la classe, mais je n'ai pas besoin de changer le code qui fait référence à la classe.
Je mélange souvent des singletons et statiques. Par exemple, j'utilise une classe de base de données qui garantit qu'il n'y a que 1 connexion à chaque maître (statique) et esclave (singleton). Chaque instance de la classe DB peut se connecter à un esclave différent, si une connexion à la même esclave est demandée, l'objet Singleton est renvoyé. La connexion principale est un objet statique instancié à l'intérieur de chaque esclave singleton, alors seulement 1 connexion principale existe sur tous les objets instanciés DB.
Je manque votre question - En fait, je suis totalement d'accord avec vous - je n'utilise jamais le modèle singleton si je peux simplement utiliser une classe statique à la place.
Ce n'est pas une question facile que je connaisse
Dans votre deuxième approche, cela vous aiderait si vous avez réellement déclaré la fonction d'être statique, c'est-à-dire. Utilisez
Fonction statique publique Ajouter ($ Log) . De cette façon, tout le monde saura que cela doit être appelé statique au lieu de devoir examiner la fonction d'abord ... des appels statiques / classes comme ceux-ci pourraient être une douleur réelle lorsque vous souhaitez démarrer des tests unitaires et se moquer de certains appels. Et c'est là que l'injection de dépendance sera utile: p.