Bonjour à tous,

Je ne crois pas qu'il existe encore un topic qui liste les différents designs pattern existant. Si je me trompe, faites-le moi savoir.

Introduction aux design patterns
Avant de développer un programme, il y a la phase de conception qui nous permet de savoir, notamment, comment écrire le code-source : ce qu'il faut utiliser, comment, etc.

Cette phase de conception permet aussi de souligner puis de se préparer à corriger les problèmes que l'on va rencontrer et, notamment, des problèmes liés à des besoins purement techniques. Exemple de problème de ce genre : je veux être sûr qu'une classe X ne sera instanciée qu'une et une seule fois.

Ce genre de problèmes peuvent donc être appréhendés durant cette phase de conception, et celle-ci permet ainsi de se préparer à les corriger quand il faudra coder. Les solutions à ce genre de problèmes sont des design patterns.

Exemple de design pattern : le design pattern "Singleton" permet de solutionner le problème énoncé précédemment, à savoir : "je veux être sûr qu'une classe X ne sera instanciée qu'une et une seule fois". En utilisant ce design pattern, on se garantit que ce problème sera solutionné et que cette solution sera propre.

Un design pattern est utilisé par tous les informaticiens, et est testé et re-testé : c'est une solution propre.

Définissons maintenant cette notion (pour l'instant je vous ai seulement expliqué ce qu'est un design pattern, mais sans vraiment apporter une définition précise).

Définition : "design pattern"
Un design pattern est donc une solution à un problème que l'on se donne. Il possède les attributs suivants :

1. Un et un seul nom (dans notre exemple : "Singleton") ;
2. Au moins un problème qu'il résout de manière élégante et sûre (dans notre exemple : "je veux être sûr qu'une classe X [...] une seule fois.".
3. Une et une seule solution (dans notre exemple : rendre le constructeur de la classe "privé", créer un attribut statique dans la classe qui contiendra l'instance de la classe, blablabla) ;
4. Un et un seul diagramme de classes UML illustrant la solution (dans notre exemple : [insérer_diagramme_UML_ici]) ;
5. Au moins une conséquence de la solution (car celle-ci peut impliquer des inconvénients ou encore des avantages à être utilisée).

Note : je vous ai préalablement dit qu'un design pattern est une solution, or là je vous dis qu'il contient l'attribut "solution". C'est normal. Il n'y a rien de bizarre. La flemme d'expliquer la différence (y en a-t-il vraiment une d'ailleurs ?), ne pinaillez pas sur ça. Avec la pratique, vous comprendrez de toute manière ce qu'est un design pattern.

Dans ce qui suit, je ne respecterai pas à la lettre cette notion d'attributs. En effet, je n'afficherai aucun diagramme UML, ni ne parlerai des conséquences, parce que bah la flemme.

Cf. mes messages ci-dessous pour les designs patterns.

Singleton

On a besoin d'être sûr que la classe Pizza ne sera instanciée qu'une et une seule fois.

Pour ce faire, on s'assure que tous les constructeurs de Pizza, même le constructeur par défaut, est privé. Pourquoi ? Parce que comme ça le programmeur ne pourra pas instancier lui-même cette classe.

Ensuite, on crée un attribut statique comme suit : private static instance : Pizza
Cet attribut, s'il vaut NULL, sera affecté grâce à une instanciation de Pizza. Sinon, on ne le modifiera pas. Nous allons tout de suite voir où effectuer cette affectation.

Il faut, après, créer une méthode statique et publique, par convention on l'appelle "getInstance", comme suit : public static getInstance() : Pizza. Cette méthode contient l'affectation conditionnée dont je viens de vous parler, et uniquement cela. Elle retourne l'attribut statique "instance".

Le programmeur devra taper "Pizza.getInstance()" pour obtenir une instance de Pizza (il ne peut en aucun cas appeler un quelconque constructeur, qui d'ailleurs sont tous privés), et cette instance sera forcément unique (explication à la ligne suivante !). En effet, getInstance vérifie que l'attribut vaut NULL pour instancier, et s'il ne l'est pas, elle n'instancie rien du tout. Donc forcément il n'y a qu'une seule instance possible.

FIN.

Sur le fond :
Tu commence par le plus controversé non ? C'est pas très recommandé en POO les singletons, et pour être dans un projet qui en possède quelques uns, c'est une vrai peine à débug et à tester

Sur la forme :
je suis pas fan des exemples en pseudo java

Ca a le mérite de bien expliquer, et c'est plutôt bien rédigé, on attend la suite