Design Pattern

Bonjour,

je programme des petites applications en c# depuis un bon bout et dernièrement j'ai découvert les design pattern que je tente d'intégrer dans la structure de mes applications. Mais bon je débute en design pattern et je n'arrive pas toujours a trouvé l'utilité d'utilisé l'un plutôt que l'autre.

J'ai donc déjà une petite application gérant des contacts, des événements et des produits. J'ai une classe Contact, Evenement, Produits qui me permette de gérer ces modules. J'ai implémenter ces classes selon le design pattern Singleton afin que chacune de celle-ci ne soit instancier qu'une fois dans toute l'application et jusqu'a dernièrement je croyais que c'était une très bonne façon de faire.

Mais j'ai découvert un pattern nommé Facade qui semble s'occuper de gérer les différents modules mais dans une seule classe. Celle-ci s'occupe d'instancier les classes nécessaire au fonctionnement de l'application.

Alors je me demandais s'il serait plus avantageux pour moi d'utiliser le pattern Facade afin d'instancier une fois chaque classe et d'utiliser la classe facade dans le restant de mon application ou de rester avec les multiples classes Singleton.

Peut-être que c'est moi qui à mal compris le principe de la Facade ou peut-être que je peux garder les deux.

Je vous demande alors votre avis là-dessus.

Salut,

Les deux patterns peuvent tres bien cohabiter puisqu'ils ne sont pas en concurrence.
Tu poses tres bien le probleme, pour pouvoir utiliser un pattern il faut connaitre son context, son applicabilite, les forces qui s'exercent dessus. Un pattern bien documente doit te donner tout ca, sinon il risque de t'induire en erreur.

En ce qui me concerne, je conseillerai de faire attention au Singleton. C'est pas parce que tu n'as besoins que d'une instance d'une classe qu'il faut l'appliquer.
Si tu n'as besoin que d'une seule instance, tu l'instancies une seule fois.
Le Singleton ne devrait s'appliquer dans des contexts plus precis: obligatoirement une seule instance, tu veux que cela soit encapsule, et tu acceptes les consequences d'avoir une variable globale (le Singleton estune variable globale).
Enfin, pour moi, tu penses au Singleton quand tu reflechies a la gestion des resources de ton appli.

Pour la Facade, c'est plus une question specification d'interface. Comment tu partitionnes des composants, qui dialogue avec qui, comment etc.
Par exemple, imagine que tu utilises une librairie, plutot bas niveau. Cette librairie t'offre une fonctionalite mais au prix de plusieurs appels aux classes, qui ont des methodes pas tres claire de ton point vue etc.
Si ta classe attaque directement cette librairie, elle va etre direcetemnt exposee a toute cette complexite.
Au lieu de ca, Facade te propose de definir une interface simple a ta classe (par exp en definnissant une meth pour acceder a la fonctionnalite), et en sous-main elle va s'occuper des appels a la librairie.

Je confirme ce que dis ndp, ce n'est pas parce qu'il n'est pas nécessaire de créer plusieurs instances d'une classe dans un programme qu'il est forcément avantageux d'utiliser un singleton.

Citation:

---

J'ai une classe Contact, Evenement, Produits qui me permette de gérer ces modules. J'ai implémenter ces classes selon le design pattern Singleton afin que chacune de celle-ci ne soit instancier qu'une fois dans toute l'application

---

Que contiennent ces classes? Les singletons sont idéals pour stocker des informations utiles que l'on est amené à devoir utiliser à différents endroits de son application. Par exemple le contenu d'un fichier de configuration...

Les cas d'utilisation qui me viennent à l'esprit sont les suivants
- Ta classe contient parmi ses membres une ou plusieurs propriétés de portée globales que tu as besoin de *partager* avec différents blocs de code de ton application.

- Ta classe est suffisamment complexe à créer pour que tu veuilles éviter de le faire à chaque fois que tu as besoin de son contenu, exemple: le constructeur accède à des ressources extérieures, à des fichiers de configuration, et prend 2-3 secondes pour créer l'objet.

Par contre, c'est superflu dans les cas suivants :

- L'objet ne contient que des méthodes (qui peuvent à ce moment-là très bien être statiques).
- L'objet n'est pas couteux ou dangereux à instancier.
- L'objet ne contient pas de propriétés à portée globale.

En gros si faire un getInstance() revient au meme que faire un new(), c'est inutile.

J'utilise aussi le singleton pour stocker l'utilisateur connecté a l'application (après un login form au départ), ainsi que ses droits d'utilisation, car cela me permet de très rapidement savoir quel est son ID (utilisé dans les documents qu'ils crée) et quels sont ses droits afin de pouvoir désactiver les menus, boutons qui ne le concernent pas.

Ainsi, peu importe ou je me trouve dans l'application il me suffit de demander l'objet pour savoir qui est connecté et j'évite de faire des accès intempestifs à la base de données lorsque j'ai besoin de savoir si une fonctionnalité est autorisée ou non.

C'était des réponses très constructive merci.

Donc si je comprend bien étant donnée que mes classes Contacts, Evenements et Produits ne sont pas très complexe à créer et qu'elle ne font que Charger ou sauvegarder des données dans des fichiers xml en applicant quelques règles d'affaire et validation, je n'ai pas besoin du Singleton pour gérer ces classes et je pourrais très bien mettre leurs méthodes GetData() et SaveData() static et ça ferais la même chose.

Effectivement, il est commun de créer des méthodes statiques dans un couche métier pour tout ce qui est stateless.

L'idée c'est que depuis ces classes, tu publies des méthodes simples qui font abstraction de ce qui est derrière (fichier XML, base de donnée, MAJ diverse).
C'est l'objectif de la façade.

Si je peux te donner un conseil, procure toi le livre "tete la premiere" (head first) sur les design patterns. Leur utilité et leur application y est très bien expliquée.

Merci pour la référence, je vais voir si je peux me procurer ce livre.

Si je comprend bien ce que tu veux dire à propos de la façade, ce serait d'appeller ma couche métier avec celle-ci. Comme ça si je change de structure de données (xml ou base de donnée) je n'aurais qu'à modifier l'appel de la couche métier dans la façade au lieu de toute l'application au complet.

Ça pourrait être une très bonne idée.

http://conception.developpez.com/livres/#livresDP
Juste pour avoir quelques ref. ;)

Ah?
J'avais même pas vu que ce livre avait fait l'objet d'une critique sur développez.com.

Citation:

---

Si je comprend bien ce que tu veux dire à propos de la façade, ce serait d'appeller ma couche métier avec celle-ci. Comme ça si je change de structure de données (xml ou base de donnée) je n'aurais qu'à modifier l'appel de la couche métier dans la façade au lieu de toute l'application au complet.

---

Oui, disons que en théorie c'est cela que l'on met en avant avec les système multi tiers. Cependant j'ai toujours trouvé que le remplacement d'une couche de stockage par une autre (XML vers BDD, BDD SQL vers Oracle) était pas forcément l'exemple le plus représentatif des avantages du n/tiers.

L'idée c'est que lorsque tu crées une application, tu crées forcément une logique métier (ajout/suppression/modification d'enregistrements, calculs etc...) que l'on souhaite pouvoir réutiliser dans le cadre d'une extension de ce projet.

Si tu mettais du code SQL Ado ou jdbc directement dans la même couche ou tu as tes fenetres UI, ca poserait un problème de réutilisabilité le jour ou tu décides d'ajouter une interface web en plus de ton application UI.
Tu serais obliger de copier-coller ta logique depuis ton UI jusque vers tes pages web, et tu devrais toujours être attentif à modifier des deux cotés lorsque tu entreprends des changements, cela conduit à des problèmes de maintenance sérieux.

En revanche, si ta couche métier est bien séparée, tu peux la réutiliser comme telle... Hélas, nombre d'outils de programmation (qui a cité *****v) prônent davantage l'approche *tout dans le meme sac*.