IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 :

Classe static ou Design Pattern Singleton ? [Singleton]


Sujet :

Design Patterns

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Août 2004
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2004
    Messages : 69
    Par défaut Classe static ou Design Pattern Singleton ?
    Bonjour,

    Quelle différence faites-vous entre une classe static et un singleton ?

    Les 2 jouent le rôle de n'avoir qu'une seule instance de classe, donc je ne vois pas vraiment l'utilité d'un Design Pattern singleton...

    Merci d'avance pour vos réponses,

    piloupy

  2. #2
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    ingénieur informaticien à la retraite
    Inscrit en
    Juin 2005
    Messages
    3 545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : ingénieur informaticien à la retraite
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juin 2005
    Messages : 3 545
    Par défaut
    une classe n'ayant que des membres statiques est un namespace déguisé et n'a donc pas besoin d'être instanciée, contrairement au singleton

    j'avoue être peu fan des singletons, comme je suis fainéant devoir écrire ClasseXX::instance()->oper(...) à la place de ClasseXX::oper(...) m'insupporte, sans parler du fait que le code passera son temps à atteindre l'instance pour rien avec en prime une éventuelle protection vis à vis du multi-tâche

    il reste cependant des cas ou le singleton et préférable, par exemple pour bénéficier d'héritage, et pour d'éventuels problèmes d'ordre d'initialisations au lancement de l'application
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  3. #3
    Membre Expert
    Avatar de hed62
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2007
    Messages
    2 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 029
    Par défaut
    Le grand intérêt de singleton est effectivement d'assurer l'existance d'une instance (donc dont l'initialisation a été faite) d'un objet. Cela permet de ne faire cette initialisation qu'une fois, au contraire de membres statics.

  4. #4
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    ingénieur informaticien à la retraite
    Inscrit en
    Juin 2005
    Messages
    3 545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : ingénieur informaticien à la retraite
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juin 2005
    Messages : 3 545
    Par défaut
    Citation Envoyé par hed62 Voir le message
    Cela permet de ne faire cette initialisation qu'une fois, au contraire de membres statics.
    je ne comprends pas en quoi il y a une différence avec les membres statiques
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  5. #5
    Membre Expert
    Avatar de hed62
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2007
    Messages
    2 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2 029
    Par défaut
    Les membres statiques d'un classe (statique elle aussi) ne bénéficie pas du traitement qui aurait pu préalablement être fait lors de la construction du singleton.

    Je m'explique par un exemple, pas forcément bien choisi, mais bon :


    Code java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    public static class MaStatique
    {
      public static object MonOperation()
      {
         //Connection à la base
         //Requete
         //retour
      }
    }
    Code java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
     
     
     
    public class MonSingleton {
       private MonSingletonInstance = null;
     
      Connection connectionALaBase;
     
       public static MonSingleton GetSingleton()
       {
           if (MonSingletonInstance = null)
              MonSingletonInstance = new MonSingleton();
           return MonSingletonInstance ;
        }
     
      private MonSingleton()
      {
         // connection à la base
      }
     
      public object MonOperation()
      {
         //Requete
         //retour
      }
    }

    Dans mon exemple, j'ai mélangé les static avec le singleton... On peut extraire tout ce qui est statique dans une Fabrique :


    Code java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
     
    // dans un namespace
     
    public class FabriqueSingleton
    {
       private MonSingletonInstance = null;   public MonSingleton GetSingleton()
       {
           if (MonSingletonInstance = null)
              MonSingletonInstance = new MonSingleton();
           return MonSingletonInstance ;
        }
     
    }
     
    public class MonSingleton {
     
      Connection connectionALaBase;
     
      protected MonSingleton()
      {
         // connection à la base
      }
     
      public object MonOperation()
      {
         //Requete
         //retour
      }
    }

    La connection à la base est faite une fois pour toute.

  6. #6
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    ingénieur informaticien à la retraite
    Inscrit en
    Juin 2005
    Messages
    3 545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : ingénieur informaticien à la retraite
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juin 2005
    Messages : 3 545
    Par défaut
    mais tu peux faire très exactement la même chose sans singleton via l'initialisation d'un des membres statiques

    par contre, comme je l'avais dit, on peut alors avoir des problèmes d'ordre d'exécution car on ne domine pas l'ordre des initialisations des membres statiques/var globales

    bien évidement il est toujours possible au pire de faire une fonction d'init appelée par le main

    le choix entre classe avec membres statiques et singleton est une question de gout. Dans Bouml je n'est pas de singleton mais des classes avec membres statiques pour la raison évoquée dans ma première réponse
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  7. #7
    Membre Expert
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    Décembre 2004
    Messages
    2 493
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2004
    Messages : 2 493
    Par défaut
    Citation Envoyé par piloupy Voir le message
    Bonjour,

    Quelle différence faites-vous entre une classe static et un singleton ?

    Les 2 jouent le rôle de n'avoir qu'une seule instance de classe, donc je ne vois pas vraiment l'utilité d'un Design Pattern singleton...

    Merci d'avance pour vos réponses,

    piloupy
    A première vue, on peut faire avec une classe statique ce que l'on peut faire avec une classe normale + pattern singleton. Seulement, la première solution ignore totalement le mécanisme d'instantiation, alors que la seconde non. En d'autres termes, la première solution ne permet pas de manipuler un objet, tandis que la seconde oui. Or, toute la doctrine objet est basé sur le traitement d'objets.

    Considérons la classe Customer possédant trois champs nom, prénom et email, plus les selecteurs et mutateurs habituels. Considérons également la classe CustomerUtil qui offre la méthode boolean validate(Customer toBeValidated) afin de valider que le contenu des champs est bien formé. Dans un contexte particulier, on peut exiger l'existence que d'un seul customer dans le système. Si vous introduisez un pattern singleton, rien ne change, vous pouvez toujours utiliser la méthode boolean validate(Customer toBeValidated). Si vous transformez Customer en classe statique, exit la notion d'objet, et toute votre conception est à revoir.

    Ce que je veux dire simplement sur cet exemple, c'est que vouloir controller l'instantiation n'a que peu d'impact sur l'existant, alors que l'utilisation de classe statique va bouleverser l'existant. Ce critère suffit à faire son choix.
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  8. #8
    Membre confirmé
    Profil pro
    Inscrit en
    Août 2004
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2004
    Messages : 69
    Par défaut
    Merci encore une fois pour toutes vos interventions. Elles ont été très enrichissantes.

    Je viens de rentrer de vacances...

    piloupy

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 6
    Dernier message: 25/10/2013, 10h16
  2. scope application et design pattern singleton
    Par totoche dans le forum Servlets/JSP
    Réponses: 1
    Dernier message: 01/10/2008, 15h56
  3. Réponses: 1
    Dernier message: 04/07/2008, 14h53
  4. Implémentation du design pattern singleton
    Par 0pierrot0 dans le forum C++
    Réponses: 1
    Dernier message: 22/01/2008, 10h01
  5. Réponses: 2
    Dernier message: 01/06/2006, 14h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo