Discussion :

[matN59]

bonsoir tout le monde

j'avais une question un peu theorique mais dont je n'arrive pas a trouver de reponse.
voila j'aurais aimé connaitre les avantages et les inconvenients des singletons et des classes avec des methodes statiques:
par exemple en php, pour ecrire une classe de configuration on peut realiser soit:
le singleton

Code :

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
30
31
32
33
34
35
36

class SingletonConfiguration {
    /**
     * the configuration instance
     * @access private
     */
    private static $instance = null;

     /**
      * get the configuration instance
      * @access public
      * @return mixed
      */
     public static function getInstance() {
        if (is_null($this->instance)) {
          $this->instance = new SingletonConfiguration();
        }
        return $this->instance;
     }
      /**
       * default constructor
       * @access private
        */
       private function __construct() {

       }

       /**
         * get a configuration key
         * @access public
         */
         public function getConfigKey($keyName) {
             ...
         }
}

et une classe avec des methodes statiques

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8

class Config {

        public static function getConfigKey($keyName) {

        }
}

dans quel cas utiliser un design pattern et non pas l'autre?
merci d'avance de votre experience
bien cordialement,

[ego]

Si tu mets uniquement des méthodes statiques, tu n'instantie pas la classe. Dans le cas d'un singleton, tu travailles sur un objet.
Tu peux donc, dans le cas du singleton, manipuler l'objet en le mettant par exemple dans une liste, hashtable ou autre.
On peut aussi dire que le singleton te prépare mieux à certaines évolutions comme le fait, par exemple, de supprimer son aspect "singleton". C'est à dire que tu vas pouvoir plus facilement supprimer cette notion d'instance unique dans la mesure où les objets qui travaille avec ton singleton travaille de manière naturelle sur un objet. Dans le cas où tu mets des méthodes statiques et travaille donc avec la classe, tu comprends bien que tout ton code qui utilise cette classe devra être modifié.

Maintenant, vu d'une autre manière, les 2 approches ne répondent pas aux mêmes objetifs.
Dans le cas de méthodes de classe (statiques), cela veut dire que les méthodes sont intrinsèquement de niveau classe. Dans le cas du singleton, ta classe ne doit par essence n'avoir d'une seule instance.
Le "problème" vient du fait que l'on utilise parfois l'une ou l'autre des approche pour faire de la programmation "fonctionnelle" sans vraiment penser aux 2 points précédents.

Au final, je te recommanderai, si tu as un doute, d'utiliser un singleton.

[matN59]

bonjour

merci pour cette reponse
donc tu me conseilles d'utiliser le modele de singleton. j'avais un doute.
le probleme est que dans mon modele actuelle, celui avec des methodes de classe statique, j'ai plusieurs objets qui heritent de ma classe.
l'heritage du modele singleton pose probleme je crois aux vues du tutorial sur les design pattern de developpez.
un exemple trivial serait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
class Config {
        
       public static function getConfigKey($keyName) {
               ...
        }
}

class ConfigAdmin extends Config {
       public static function getConfigPassword() {
           return parent :: getConfigKey('password');
       }
}

comment peut on ecrire cette notion d'heritage en gardant toutes les proprietes du singleton?

On peut aussi dire que le singleton te prépare mieux à certaines évolutions comme le fait, par exemple, de supprimer son aspect "singleton". C'est à dire que tu vas pouvoir plus facilement supprimer cette notion d'instance unique dans la mesure où les objets qui travaille avec ton singleton travaille de manière naturelle sur un objet.

je n'ai pas bien compris ce point. tu aurais un exemple trivial ?
merci pour ton aide

[ego]

Une solution est de passer par une fabrique auprès de laquelle tu vas enregistrer tous tes "singletons".
Tes "singletons" ne seront en fait pas des singletons mais des classes classiques. Tu ne les récupèrera pas directement en t'adressant à leur classe mais en passant par la fabrique.
Au lancement de ton application, tu instancie un objet de chaque "singleton" et tu enregistre chaque objet auprès de la fabrique en donnant un nom différent à chaque fois (le nom complet de la classe par exemple - la fabrique contenant une hashtable de couples nom/singleton). Ensuite, on récupère toujours ces "singletons" en demandant le "singleton" à la fabrique.
C'est exactement comme cela que fonctionne le framework SPRING.
Une variante de cette solution est de faire que la fabirque ne soit pas une classe à part mais tout simplement la classe de base de tous tes singletons.

[matN59]

rebonjour

donc j'ai bien compris l'implementation de la factory.
par contre, ce qui me gene un peu, c'est que je vais avoir une instance de chaque :
en php, (desolé c'est le langage que je connais le mieux, en java ca m'aurait pris beaucoup plus de temps ), cela donnerait:
la factory

Code :

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
30
require_once 'ConfigSingleton.php';
require_once 'ConfigAdminSingleton.php';
/**
 * definition de la factory de config
 */
class ConfigFactory {
    /**
     * le hashtable contenant les singletons de configuration
     * @access private
     */
    private $configObjects= array();
    /**
     * le constructeur
     * @access public
     */
    public function __construct() {
        $this->configObjects['confg'] = ConfigSingleton :: getInstance();
        $this->configObjects['confgAdmin'] = ConfigAdminSingleton :: getInstance();
    }
    
    /**
     * retourne l'instance du singleton desiré
     * @access public
     * @return mixed
     */
    public function getConfig($configType) {
        return $this->configObject[$configType];
    }
}

ConfigSingleton

Code :

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
30
31
32
33
34
35
36
37
38
/**
 * definition du singleton de configuration
 */
class ConfigSingleton {
    /**
     * the configuration instance
     * @access private
     */
    private static $instance = null;

     /**
      * get the configuration instance
      * @access public
      * @return mixed
      */
     public static function getInstance() {
        if (is_null($this->instance)) {
          $this->instance = new SingletonConfiguration();
        }
        return $this->instance;
     }
      /**
       * default constructor
       * @access protected
        */
       protected function __construct() {

       }

       /**
         * get a configuration key
         * @access public
         */
         public function getConfigKey($keyName) {
             ...
         }
}

ConfigAdminSingleton

Code :

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
30
31
32
33
34
35
36
37
38
39
/**
 * definition du singleton de configuration admin
 */
class ConfigAdminSingleton extends ConfigSingleton {
    /**
     * the configuration admin instance
     * @access private
     */
    private static $instance = null;

     /**
      * get the configuration instance
      * @access public
      * @return mixed
      */
     public static function getInstance() {
        if (is_null($this->instance)) {
          $this->instance = new SingletonConfiguration();
        }
        return $this->instance;
     }
      /**
       * default constructor
       * @access private
        */
       private function __construct() {
            parent :: __construct();
       }

       /**
         * retourne un password
         * cette methode appelle la methode getConfigKey definit au niveau du ConfigSingleton
         * @access public
         */
         public function getConfigPassword() {
             return $this :: instance->getConfigKey($password);
         }
}

dans ce cas, je vais me retrouver avec une instance de chaque classe de configuration conservée en attribut de la factory.
au niveau mémoire, meme si mes classes - pour le moment avec des attributs statiques - ne font pas de traitement lourds, est ce que cette implementation n'est pas plus gourmande en mémoire?
tu vas surement me dire que l'implementation de mes classes derivées de la classe ConfigSingleton ne servent a rien au niveau d'un nouvel objet puisque elles peuvent etre implementées au niveau de la definition de la classe mere. si je suis passé par cette methode, c'est tout simplement pour faire un decoupage fonctionnel, pour une meilleur lisibilité du code, et pour eviter d'avoir a centraliser toutes mes methodes pour determiner mes parametres de configuration au sein d'un seul objet.

au niveau utilisation mémoire, a ton avis quelle est la meilleure implementation?
au niveau logique et "propreté" de l'implementation?
merci de ton aide

[ego]

Premièrement, ton code est ok. Il correspond bien à ce que j'ai essayé d'expliquer.
Pour l'histoire de la mémoire, c'est à toi de voir. Si cela te pose un problème, en Java tu peux utiliser l'API de réflection.
C'est à dire que tu vas, au départ, stocker des couples [clé, nom de classe]. Ensuite, au premier appel à ta fabrique, tu regardes si l'instance a déjà été créée. Si oui tu la donnes, si non, tu prends le nom de la classe et tu utilise Class.forName(<nom de classe>) pour avoir une instance de l'objet "Class" associé à l'objet que tu veux créer et ensuite sur cet objet "Class" tu appelles la méthode newInstance.
Au final, dans ta fabrique tu as une hastable qui stocke des couples [nom de classe, instance unique], la clé pouvant être d'ailleurs le nom de la classe.
Pour être plus précis, c'est plutôt comme cela que fonctionne SPRING.

[matN59]

merci pour ton aide