Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Design Patterns Discussion :

Problème de conception


Sujet :

Design Patterns

  1. #1
    Membre confirmé
    Problème de conception
    Bonjour,

    Lorsqu'on utilise le singleton, on peut imaginer se retrouver dans le cas où celui-ci est détruit avant qu'un appel à getInstance soit effectué pour récupérer ses paramètres (qui ne sont plus car on instancie un nouvel objet singleton au getInstance...)

    Quelle est la meilleure façon de pallier à ce problème ?

    Merci

  2. #2
    Membre habitué
    Bonjour,

    Je pense que l'utilisation 'classique' du singleton est tout simplement de ne jamais détruire l'objet singleton. Au mieux une seule fois, juste avant que le programme se termine.

    Si votre application nécessite la destruction de l'objet, c'est probablement que les paramètres en question n'était plus valables.

    S'il y a des paramètres qui doivent malgré tout subsister en dépit de cette destruction, je vois deux cas :
    • Ce sont des constantes : les définir en membres de classe et non d'objet (déclarés en 'const' évidemment)
    • Les paramètres doivent avoir des durées de vie différentes : Votre singleton a probablement trop de responsabilités. Vous devez le décomposer en deux singletons (ou plus) différents, un par responsabilité identifiée.


    qui ne sont plus car on instancie un nouvel objet singleton au getInstance...
    Je n'ai pas bien compris cette phrase.
    Si vous voulez dire que les paramètres ne sont pas initialisés ou mal suite à la nouvelle instanciation, vous pouvez enrichir la méthode getInstance() pour remplir les paramètres que le constructeur ne pouvait pas deviner.
    Si la méthode getInstance n'est pas non plus capable de correctement remplir les paramètres, vous avez probablement un problème de dépendance dans votre classe, et vous devez vérifier que les paramètres en question soient vraiment à leur place dans cette classe.

  3. #3
    Membre confirmé
    Salut et merci tristan_m pour ton aide

    Je pense que l'utilisation 'classique' du singleton est tout simplement de ne jamais détruire l'objet singleton. Au mieux une seule fois, juste avant que le programme se termine.
    Tout à fait d'accord mais je pars du principe que sur un projet à plusieurs, quelqu'un peut malencontreusement le détruire avant la fin du programme et donc entraîner ce genre de comportement, d'où un manque de robustesse.

    qui ne sont plus car on instancie un nouvel objet singleton au getInstance...
    Je n'ai pas bien compris cette phrase.
    Ce que je veux dire ici, c'est que si jamais des valeurs ont été définies dans le singleton et que ce dernier est détruit, on ne retrouvera pas les valeurs à la nouvelle instanciation.

    Les paramètres doivent avoir des durées de vie différentes : Votre singleton a probablement trop de responsabilités.
    Je pense que l'idée est bonne oui. Il faudrait peut être que le singleton puisse venir changer les valeurs sans pour autant que ces dernières soient influencées par sa destruction. Après, il faut que la destruction des données se fassent ailleurs.

  4. #4
    Membre confirmé
    Bonjour


    Ce que je veux dire ici, c'est que si jamais des valeurs ont été définies dans le singleton et que ce dernier est détruit, on ne retrouvera pas les valeurs à la nouvelle instanciation.

    Dans quel environnement parlez vous?. Si vous êtes en PHP votre classe de type singleton sera détruite au même titre que n'importe quelle autre classe à la fin de l'exécution de votre script, et tout comme n'importe quelle autre classe vous pouvez persister votre singleton dans votre application et récupérer les valeurs que vous voulez à la nouvelle instanciation.

    Je vous rappelle à ce titre l'un des principes mêmes de la programmation orientée objet : l'encapsulation. A ce titre c'est votre singleton qui lui même décide si on peut le détruire ou non et sous quelles conditions, personne d'autre ni n'importe quel autre objet.

    Jc.
    _______________________________________
    POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
    Blog TSE sur developpez.com : Architectures web hautes performances en PHP
    Les meilleurs tutoriels PHP sur developpez.com

###raw>template_hook.ano_emploi###