Presentation Transcript

1. Designs Patterns comment rendre son code faiblement couplé, et maintenable...
2. Constat : Hormis les algorithmes métier,les difficultés de l’ingénierie de code sont souvent identiques ! Les solutions mises en œuvres sont (trop) souvent dépendante de l’imagination du développeur…  Pourquoi réinventer la roue, alors que nos douleurs quotidiennes ont été étudiées par d’autres avant nous ? Par masochisme ? Par sadisme ?  Une solution : Les Designs Patterns ! Ce sont un ensemble de recettes permettant de résoudre les principaux problèmes liés à l’ingénierie de code, Objectif :Garder un code ouvert au changement, mais fermé aux modifications,
3. Fondements des DP GOF (Gang of four) N’est pas le groupe de musique post-punk des années 70… Mais plutôt les 4 créateurs à l’origine des DP ! « Chaque patron décrit un problème qui se manifeste constamment dans notre environnement, et donc décrit le cœur de la solution à ce problème, d’une façon telle que l’on puisse réutiliser cette solution des millions de fois, sans jamais le faire deux fois de la même manière » 23 patterns de « base » Quel que soit le langage, ou la technologie objet ! Tous les autres sont des dérivés... (MVVM, ...)
4. 3 Types Création (Creational Patterns)Singleton, Factory, Abstract Factory, Prototype Structural (Structural Patterns)Adapter, Facade, Proxy,... Comportements (Behavioral Patterns)Strategy, Chain of responsability, Iterator, Observer, ...
5. Formalisme
6. Entrons dans le vif du sujet
7. Le pattern Sssssssss
8. Nom : SssssssssType : ComportementBut : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. Exercice : Etape 1 Un client désire une FPS de canards...Un canard a un nom, peut nager, cancaner et doit être affiché. Bug ! les canards en plastique qui étaient dans l’application (des leurres en quelque sorte) se mettent à voler... Nous avons donc un problème de conception ! Quelles solutions d’après vous pourraient apporter implémentation pérenne, en d’autres termes : Disposer d’une application fermée aux modifications mais ouverte aux changements ? Etape 2 Lors de la release de la version, le client note que tout les canards nagent et cancanent de la même manière... c’est MAL !. Etape 3 L’année suivante, le client désire ajouter une évolution : les canards savent voler...
9. Nom :SssssssssType : ComportementBut : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. Que proposez vous comme solutions ? Héritage ? Interfaces ? Reprenons de la hauteur ! Quel est le réel problème ? LE CHANGEMENT !
10. Nom : SssssssssType : ComportementBut : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. LA VRAIE question porte donc sur ce qui change : Quels sont les différences entre les différents canards ? réponse : leur comportement... (vol, cancan, affichage)
11. Nom :Stratégie (Strategy)Type : ComportementBut : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. etc. Cancan
12. Nom : Stratégie (Strategy)Type : ComportementBut : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. Exemple de stratégie
13. Nom : Stratégie (Strategy)Type : ComportementBut : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. Exemple de Contexte
14. Nom : Stratégie (Strategy)Type : ComportementBut : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. Exemples réels : Une application de paiement en ligne peut offrir différents moyens de paiements, il suffit de choisit la bonne stratégie en fonction du choix du client. Car hormis le mode de paiement, la suite du flux de commande demeure identique... En .net, la classe ArrayList (contexte) est une bon exemple. La méthode sort par défaut offre une implémentation (stratégie concrète) par défaut. Cette méthode peut être substituée par l’implémentation fournie à l’exécution (implémentation de l’interface IComparer - stratégie)...
15. Nom : Stratégie (Strategy)Type : ComportementBut : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. Retour sur les brèves de comptoir ... Il est préférable d’implémenter des interfaces ! Encapsuler ce qui change est un gage d’évolution ! La composition est préférable à l’héritage ! L’héritage est un concept qui s’applique au modèle métier (le plus souvent). Un code doit être ouvert au changement, mais fermé aux modifications... Privilégier le couplage faible favorise l’évolution...
16. Le pattern Aaaaaaa
17. Nom :AaaaaaaType : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Reprenons notre SuperCanard...Un jour, notre client favoris rachète un produit concurrent : Super Dindes. Il vient nous voir, car il désire créer une édition spéciale : Dindes VS Canards
18. Nom :AaaaaaaType : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Reprenons notre précédent projet... ? Quelle était le sujet de Super Canards ? Quelles étaient les contraintes ? Quelle solution(s) avons nous apporté ?
19. Nom :AaaaaaaType : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Petit rappel...La classe Duck, et les strategies de comportement...
20. Nom :AaaaaaaType : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Petit rappel...La classe Duck, et les strategies de comportement...
21. Nom :AaaaaaaType : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Retour sur les brèves de comptoir ... Il est préférable d’implémenter des interfaces ! Encapsuler ce qui change est un gage d’évolution ! La composition est préférable à l’héritage ! L’héritage est un concept qui s’applique au modèle métier (le plus souvent). Un code doit être ouvert au changement, mais fermé aux modifications... Privilégier le couplage faible favorise l’évolution...
22. Nom :AaaaaaaType : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. VS Quelles solutions pourraient apporter une solution simple, rapide... et maintenable ?
23. Nom :AaaaaaaType : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Cela jacasse dur autour de ce concept ! Mais en termes d’implémentation cela donne quoi ?
24. Nom : Adaptateur (Adapter)Type : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Interface de canards... IHM gérant exclusivement des canards... Adaptateur canards-dinde Dinde
25. Nom :AaaaaaaType : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Revenons à nos mouton...ou plutot à nos canards, et dindes... En sachant ce que vous savez, quelle serait l’application du pattern Adapter ?
26. Nom : Adaptateur (Adapter)Type : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Solution = 3 adaptateurs : - Adaptateur de comportement de nage, - Adaptateur de comportement Quack, - Adaptateur permettant de transformer une dinde en canard
27. Nom : Adaptateur (Adapter)Type : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Il est donc nécessaire d’adapter notre dinde aux concepts manipulés... (comportements) (ceci est nécessaire pour adapter la dinde à l’implémentation existante) Adaptateur pour passer d’un comportement lié à la classe au pattern stratégie Interface Dinde - Duck différente... A l’initialisation, fournir à l’adaptateur l’objet adapté !
28. Nom : Adaptateur (Adapter)Type : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Il est donc nécessaire d’adapter notre dinde aux concepts manipulés... (duck) (ceci est nécessaire pour adapter la dinde à l’implémentation existante)
29. Nom : Adaptateur (Adapter)Type : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Utilisation... 2 3 1 Attention : un canard peut masquer une dinde...
30. Nom : Adaptateur (Adapter)Type : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Un oeil dans le code ? une démo ?
31. Nom : Adaptateur (Adapter)Type : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. ... et dans la vraie vie... le concret du réel... pouvez vous me donner des exemples decette implémentation ...? Adaptateur .net - COM, Adaptateur entre dll third party et main app, Fonctionnement des addons, Hors informatique ? des adaptateurs de prise UK - FR, les réducteurs de wc pour enfants, les réducteur pour dock d’ipod etc.
32. Nom : Adaptateur (Adapter)Type : StructuralBut : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Retour sur les brèves de comptoir ... Il est préférable d’implémenter des interfaces ! Privilégier le couplage faible favorise l’évolution... Encapsuler ce qui change est un gage d’évolution ! L’héritage est un concept qui s’applique au modèle métier (le plus souvent). Un code doit être ouvert au changement, mais fermé aux modifications... Ce n’est ni à la classe métier, ni au contexte à devoir s’adapter... La composition est préférable à l’héritage !
33. Le pattern eeeeeeee
34. Techniquement, nulle part... mais en ce qui concerne la gestion du changement il s’agit d’une autre affaire ! Et où est le problème ? Nom :EeeeeeeeType : CreationalBut : Centraliser l’instanciation d’objets. Jusque là, pour instancier des objets nous placions des new là où nous en avions besoin...
35. Nom :EeeeeeeeType : CreationalBut : Centraliser l’instanciation d’objets. En implémentant des interfaces, nous isolons le code des changements qui peuvent se produire en aval. En s’appuyant sur une interface, le code client continuera de fonctionner lors du remplacement d’une classe, et ce par polymorphisme. Le couplage est donc faible.
36. Nom :EeeeeeeeType : CreationalBut : Centraliser l’instanciation d’objets. En codant nos classes sans interface, il est nécessaire de « réouvrir » le code aux modifications pour prendre en compte à chaque changement de classe.
37. Nom :EeeeeeeeType : CreationalBut : Centraliser l’instanciation d’objets. Comment éviter le coté obscure ? Identifier ce qui changeetL’externaliser ! souvenez vous des patterns stratégie et adapteur... PS : Cette règle vaut pour tous les patterns...
38. Nom :EeeeeeeeType : CreationalBut : Centraliser l’instanciation d’objets. Bonjour Messieurs, J’ai l’honneur de vous annoncer que vous avez été sélectionnés pour la réalisation de notre application de gestion de pizzérias. Félicitations ! Luigi Del Gusto
39. Nom :EeeeeeeeType : CreationalBut : Centraliser l’instanciation d’objets. En tant pour bon concepteur, comment aller vous mettre en oeuvre cette application de pizza ?
40. J’en ai l’eau à la bouche ! Nom :EeeeeeeeType : CreationalBut : Centraliser l’instanciation d’objets. Evolution : Pour fêter les transhumances, Luigi désire ajouter à la carte des spécialités régionnales : - pizza raclette, - pizza reblochonne, - pizza au gorgonzola
41. Nom :EeeeeeeeType : CreationalBut : Centraliser l’instanciation d’objets. Scoop : Une nouvelle évolution pointe le bout de son nez : Luigi revient nous voir, il a monté des pizzerias dans les quatre coin de France et Navarre. Il désire maintenant s’exporter... Or les pizza allemande portent le même nom que les françaises, seul la composition peut varier... Le processus de fonctionnement des pizzerias demeure le même...
42. Nom :EeeeeeeeType : CreationalBut : Centraliser l’instanciation d’objets. Qu’allez vous mettre en place pour permettre d’étendre l’application, tout en gardant le code fermé au maximum ?
43. Nom :Fabrique (Factory)Type : CreationalBut : Centraliser l’instanciation d’objets. La solution : La notion de fabrique et le pattern « fabrique abstraite »
44. Nom : Fabrique simple (Factory)Type : Creational Contrat : Interface ou classe abstraite (italique) Fabrique pizza App pizzeria Contrat : Interface ou classe abstraite (italique) Pizza napolitaine fabrique Fr fabrique DE Napo FR Napo DE Implémentationde la fabrique Implémentationdes pizzas sur base des contrats Pizza 4 froms 4 froms FR 4 froms DE
45. Nom : Fabrique (Factory)Type : Creational Une dernière notion : le client consomme la «bonne fabrique abstraite» via une méthode « fabrique » consomme
46. Nom : Fabrique (Factory) Type : Creational Un oeil dans le code ? une démo ?
47. Nom : Fabrique (Factory) Type : Creational Pourquoi favoriser l’utilisation des principes de fabrique et fabrique abstraite ? Les constructeurs sont assez limités dans leur processus de création : ils retourne une instance de xxx. Pour permettre une plus grande évolutivité, les fabriques permettent de découpler les logiques d'interactions, de l’implémentation... Ce qui permet de masquer l’implémentation au consommateur de classes...
48. Nom : Fabrique (Factory) Type : Creational Pourquoi favoriser l’utilisation des principes de fabrique et fabrique abstraite ? Régulièrement, nous sommes confrontés à des incertitudes du client. Les choix permettant de levés ces incertitudes peuvent être repoussés à plus loin, sans pour autant bloquer le développement des applications. Exemple : Ado.net permet de masquer, et de paramétrer l’implémentation utilisée via les chaines de connexions. Pour ce faire, nous pouvons utiliser l’espace de nom Db : DbConnection, DbCommand, DbDataAdapter
49. Nom : Fabrique (Factory) Type : Creational Pourquoi favoriser l’utilisation des principes de fabrique et fabrique abstraite ? Les constructeurs ne laissent pas toujours deviner de leurs intentions réelles. Imaginons une classe, avec de multiples constructeurs : public Vehicle (intpassengers) public Vehicle (intpassengers, inthorsePower) public Vehicle (intwheels, booltrailer) public Vehicle (string type)
50. Nom : Fabrique (Factory) Type : Creational Pourquoi favoriser l’utilisation des principes de fabrique et fabrique abstraite ? La factory clarifie rapidement l’intention du développeur public VehicleCreateCar (intpassengers) public VehicleCreateSuv (intpassengers, inthorsePower) public VehicleCreateTruck (intwheels, booltrailer) public VehicleCreateBoat () public VehicleCreateBike ()
51. Nom : Fabrique (Factory) Type : Creational Pourquoi favoriser l’utilisation des principes de fabrique et fabrique abstraite ? Vous verrez que derrière le terme de fabrique, nous retrouvons souvent à la fois des fabriques abstraites et des méthodes de fabriques. En .net, les méthodes fabriques sont surtypées par Factory.
52. Nom : Fabrique (Factory) Type : Creational Encapsuler ce qui change est un gage d’évolution ! Retour sur les brèves de comptoir ... Privilégier le couplage faible favorise l’évolution... Il est préférable d’implémenter des interfaces ! Les composants applicatifs consomment les instances, mais ne sont pas responsables de leur instanciation Un code doit être ouvert au changement, mais fermé aux modifications... Les interfaces sont des contrats remplis par certaines instances, et consommés par d’autres Centraliser les créations d’instances favorise la dissociation entre modèle et comportement. Le « new » n’est pas si anodin que cela !