Instance avec deux implémentations possible

Bonsoir à tous,

j'ai une question de conception pour un programme et je ne sais pas comment m'y prendre...

en fait j'ai une partie de mon code qui instancie un Objet de type ObjetGenerique, et selon un paramètre de config (mode DEV ou PROD) j'aimerais que cet objetGenerique puisse insancier une implémentation différente.

En mode DEV j'utilise des méthodes "bouchon" pour ma valid, et en mode PROD j'utilise les méthodes "officielles" pour avoir un comportement complet de mon programme.

donc pour ce faire, je me suis penché sur une interface ObjetGenerique qui a deux implementation, ObjetModeDev et ObjetModeProd, par contre je ne sais pas comment avoir un code générique en amont qui serait

Code:

---

mon_objet = new ObjetGenerique();

---

et que en fonction de mon paramètre aille utiliser l'une ou l'autre implémentation.

j'espère avoir été clair...
avez vous une idée ?

Merci,
Tiamat.

Salut,
fais une recherche sur le site ou sur le net avec Pattern Factory.
Il s'agit d'un pattern d'instanciation de classes qui te sera utile. Tu te retrouveras au final avec un truc du style :

Code:

---

ObjetGenerique o = OFactory.getObject();

---

Ensuite t'auras juste à modifier soit ta méthode statique getObject() pour qu'elle te retourne une instance de la classe que tu veux. Ou encore, tu lui passes un paramètre pour définir si t'es en mode prod ou dev.

Code:

---

1 2 3 4 5 6

public static ObjetGenerique getObject(int mode) { if(mode = 0) { return new ObjetDev ; } return new ObjetPro; }

---

D'autre part, es-tu sûr que tu n'as pas des choses en commun pour tes 2 types objets, il y a de fortes chances qu'une classe abstraite soit plus appropriée, mais je n'ai pas vu ton code.
Tu peux aussi jeter un coup d'oeil au pattern décorateur (décoration) mais la Factory devrait te suffire.

Salut Djakisback,

merci de ta réponse et effectivement le Pattern Fctory semble être la solution pour moi !
en ce qui concerne ta question sur la classe abstract, effectivement ça pourrait effectivement être une solution pour mon problème.

J'ai trouvé un tuto sur les Design Pattern sur notre cher site developpez.com ;)

Je jette un coup d'oeil et je voit ensuite ce qui est le plus approprié.

Merci en tout cas du coup de pouce !

A Bientot,
Tiamat.

En fait, quand je parlais de classe abstraite, je voulais dire que ce serait plus approprié qu'une interface. En revanche, ça ne résoudra pas ton problème ^^

Bonjour,

Pour le décorator je pense que c'est une très mauvaise solution, ca provoquerais de biens trop grand changements pour basculer entre dev/prod.

Pour la factory (voir une abstract factory), même si techniquement ca répondrait très bien au problème, je pense que c'est également une mauvaise solution.

En fait, utiliser une factory provoquerait :
1/ une prolifération des classes inutile.
2/ une dégradation (même mineure) des perfs.
3/ trvailler inutilement (oui on est faignant :aie:)

Généralement, on fait un module de test, que l'on run pour effectuer divers tests (lequels pourront utiliser junit si besoin il y a) au lieu de run l'application proprement dite.
Dans la pratique ca se traduit souvent par un script ant qui qui aura au moins deux target :
* make-test (ou make-dev)
* release

En fonction de la target, on construira les sources à compiler à partir de fichiers dans des arborescences différentes.

Cette solution à l'avantage de :
1/ ne pas toucher ton code existant
2/ aucun changement au niveau des perfs
3/ au lieu de coder/mettre en place des factories (voir des abstract factories), on fera du XML.

Pour finir, il y a toutes les chances que ton IDE intègre directement l'éxecution de script ant.

Salut Alain Defrance,

effectivement j'utilise déjà Ant pour builder mon projet donc je vais également voir cette solution, en mettant une option de compil de Build qui me permettra de sélectionner une implémentation de mon interface ou une autre.

Mais c'est tout à fait le but de ce mode Dev, pour lancer une valid sur une partie du code bien particulière sans lancer une partie spécifique qui utilise une communication USB (et donc a sa propre campagne de valid).

Merci pour ces infos précieuses.
Tiamat.

Effectivement, je n'ai pas réfléchi au problème de fond :oops:

Citation:

---

Mais c'est tout à fait le but de ce mode Dev, pour lancer une valid sur une partie du code bien particulière sans lancer une partie spécifique qui utilise une communication USB (et donc a sa propre campagne de valid).

---

Je pense que tu as séché tes cours sur les tests unitaires et les mock objects. :mouarf:

lol c'est pas faux mais pas vraiment le problème...
c'est juste d'agencer mon code pour avancer à la fois sur mes tests et à la fois sur la valid. la com USB est un peu lente et je pense que je pourrais accélérer tout ça.

bon j'avoue quand même qu'au niveau tests unitaires et Mocks je pêche un peu ! si vous avez deux trois tutos qui peuvent m'aider je suis preneur !

Citation:

---

mais pas vraiment le problème...

---

D'après ce que je comprends, c'est le problème. Tu utilises un bout de code faisant un accès usb. Si tu masques ce code via une interface, tu peux alors créer dans tes tests unitaires un mock qui simule le comportement de l'accès usb, sans réellement le faire.
Il y a de très bons cours sur le site à ce sujet.

Merci Patrirarch24, j'ai commendé à implémenter mes tests JUnit en me basant sur un mock pour simuler mes accès USB.

merci à tous
Tiamat.

chut ne le divulguez pas: il y a aussi un horrible "hack" pour faire ça::twisted:
une assertion avec un effet de bord qui passe la main à un objet Proxy. Quand les assertions sont activées on appelle une méthode (qui rend toujours true) mais qui remplace l'objet cible par un Proxy (dynamique ou pas) .....
la dite méthode peut être sophistiquée au point de consulter un fichier de configuration, etc....

Citation:

---

Envoyé par professeur shadoko

chut ne le divulguez pas: il y a aussi un horrible "hack" pour faire ça::twisted:
une assertion avec un effet de bord qui passe la main à un objet Proxy. Quand les assertions sont activées on appelle une méthode (qui rend toujours true) mais qui remplace l'objet cible par un Proxy (dynamique ou pas) .....
la dite méthode peut être sophistiquée au point de consulter un fichier de configuration, etc....

---

:vomi:

En un mot : Guice.

Ouaip l'ioc est un moyen de solutionner le problème, si l'on accepte la dépendance vers un framework supplémentaire.