[Article] Comprendre les différents design patterns de construction

Bonjour,

Cette discussion a été ouverte afin de recueillir vos commentaires ou vos remarques sur l'article Comprendre les différents design patterns de construction lorsque le lien sera posté le 4 avril.

Bonne future lecture à tous. :ccool:

C'est marrant, il y'a quelque temps, j'avais acheté un livre sur les designs patterns en C# et il y'avait les mêmes "erreurs":
Pourquoi créer une méthode Instance() ou setControleur() en C# ?? Les propriétés avec les getters/setters sont la pour ca. Alors ok, ca colle à l'UML et ca ressemble au Java mais je trouve dommage de s'en priver :(

Note: Je ne t'en veux pas particulièrement hein, c'est juste que je suis frustré d'avoir acheté ce bouquin :mouarf:

Edit:
-Ah et puis je chipote mais c'est dommage de pas respecter les conventions de casse sur les noms de méthodes
-Autre détail: Le lien forum dans le cadre bleu de résumé n'est pas le bon ca pointe vers un article sur les services en .Net

Citation:

---

Envoyé par Nathanael Marchand

Pourquoi créer une méthode Instance() ou setControleur() en C# ?? Les propriétés avec les getters/setters sont la pour ca.

---

Complétement d'accord. Je gère mes singletons de la même manière.
C'est le design pattern qui doit être adapté dans le code en question, par l'inverse.

Voici le lien de l'article.

Merci pour vos remarques, je comprends tout à fait vos points de vue et c'est vrai que ça aurait été plus approprié d'utiliser les getters/setters.

PS : le lien forum est corrigé et pointe ici maintenant. ;)

Bonjour,
Je me pose une question. Pourquoi les attributs déclaré dans la classe abstraite sont-elles répété dans les classe enfants. Je pense à chipset par exemple. La notion d'héritage devrait fonctionner pourtant. Y aurait-il une raison particulière ?

Merci

Autre question, concernant le point 3.1 :

Quel est l'utilité de ces lignes là ? (idem pour CarteMerePortable, CarteGraphiquePortable, CarteGraphiqueFixe)

Code:

---

1 2 3 4 5 6

public CarteMereFixe(String modele, String chipset) : base(modele, chipset) { this.modele = modele; this.chipset = chipset; }

---

Est-ce que ça ne suffirait pas :

Code:

---

1 2	public CarteMereFixe(String modele, String chipset) : base(modele, chipset) { }

---

J'ai toujours considéré Abstract Factory comme étant une factory généraliste fournissant une Factory spécialisée, et donc que le code suivant se situe lui dans la factory de base :

Code:

---

1 2 3 4 5 6 7 8 9

if (choix.Equals("1")) { ordinateur = new OrdinateurFixe(); } else { ordinateur = new OrdinateurPortable(); }

---

Qui serait appelé par un code du genre :

Code:

---

1 2	Ordinateur ordi = OrdinateurFactory.Create(TypeOrdinateur.PC); ordi.Create...();

---

Après ça reste discutable du à l'implémentation : Un Ordinateur qui crée ses pièces au lieu d'en être composé :aie:

Décorateur ne rentre pas dans la liste de Construction ?

Tout d'abord, merci pour ce tuto sur les design patterns de conception, la quantité de boulot derrière ne semble pas négligeable :ccool:

Ceci dit, j'avoue avoir lu pas mal de design patterns ici et là, et encore une fois les versions ne se confirme pas. En tout cas sur les factory abstraite ou non.

Là sous le coude, en allant sur wikipedia (ok c'est en java) on peut voir que tout se limite à l'utilisation d'interface que l'on soit en abstraite ou non.

De plus, sur mon premier projet de framework, l'architecte avait mis en avant l'abstract factory, mais utilisé comme tu l'a présenté en "factory" simple. Et j'ai vu cette implémentation dans d'autres boites, je n'avais jusqu'ici jamais remis en cause son choix.


Bref, utiliser des design patterns n'a jamais été simple...

Salut,

Citation:

---

Envoyé par Arnard

J'ai toujours considéré Abstract Factory comme étant une factory généraliste fournissant une Factory spécialisée

---

+1
Pour moi une factory est générique, comme ici: http://dotnet.developpez.com/faq/asp...#adonet_select. Dans ton exemple ce n'est pas le cas. Tu as deux factory qui ne créent qu'un seul type d'objet. Je vois pas l'intérêt:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

static void Main(string[] args) { FabriqueDisqueDur disqueDurATA = new FabriqueDisqueDurATA(); disqueDurATA.creerDisqueDur("ATA");   FabriqueDisqueDur disqueDurSCSI = new FabriqueDisqueDurSCSI(); disqueDurSCSI.creerDisqueDur("SCSI");   Console.ReadKey(); }

---

Si on suit ton code il serait plus logique de faire ceci

Code:

---

1 2 3

FabriqueDisqueDur disqueDurATA = new FabriqueDisqueDurATA(); disqueDurATA.creerDisqueDur();

---

J'aurais plutôt fait

Code:

---

1 2 3

FabriqueDisqueDur factory = FabriqueDisquesDurs.GetFactory("ATA"); DisqueDurATA disqueDurATA = factory.creerDisqueDur();

---

Dans le meilleur des cas il faut utiliser des interfaces (IFabriqueDisqueDur, IDisqueDur).

Code:

---

1 2 3

IFabriqueDisqueDur factory = FabriqueDisquesDurs.GetFactory("ATA"); IDisqueDur disqueDurATA = factory.creerDisqueDur();

---

De plus dans ton exemple, tu ne fais rien du disque dur retourné par ta méthode "creerDisqueDur", dommage.

Immo

Ca ne serait pas plutôt Comprendre les différents patterns de construction en Java ??

Sur le fond, effectivement la présentation est claire, mais ça ressemble plus à du Java qu'à du C#.

La généricité ainsi que les expressions Lambda/ les délégués apportent beaucoup dans les patterns de construction.

Là j'ai l'impression de résoudre la construction d'objets en jdk 1.4.

Je suis étudiant en informatique et je trouve cet article vraiment très intéressant. J'avais une question sur les images. Quel est le logiciel utilisé pour créer les schémas ?

Merci

Si cela t'intéresse, j'avais écrit un article sur les patrons de conception dans le framework .Net
http://auriou.wordpress.com/2013/09/...-framework-net