comment rendre son code faiblement couplé, et maintenable... Designs Patterns comment rendre son code faiblement couplé, et maintenable...

Une solution : Les Designs Patterns ! 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 ?  Recettes : - l’ingénierie de code se résume à un ensemble de problèmes récurrents qui peuvent êtres résolus d’entrée de jeu si on utilise ces recettes... - Ces recettes ont mis des années à être mises au jour... il s’agit du fruit du travail d’en ensemble d’architectes et d’équipes expérimentées. - Les grands acteurs de l’ingénierie (Sun, IBM, Oracle, MS, Google, etc) exploitent ces recettes au sein de nombreux logiciels... ce qui permets de les rendre maintenable ! 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,

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, ...) GOF : 4 architectes, parents des études quant à la mise au jour des recettes,

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, ...

Formalisme

Entrons dans le vif du sujet

Le pattern Sssssssss

Nom : Sssssssss Type : Comportement But : 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 3 : porter l’attention sur - le nombre de modifs de code nécessaires à l’implémentation - sur le fait que les leurres étaient présent depuis le début... mais que leur problème est survenu lors de l’évolution ! 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...

Nom : Sssssssss Type : Comportement But : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. Que proposez vous comme solutions ? Héritage ? Lorsqu’une solution est mensionnée, et non encore implémenté, solliciter l’assemblée à apporter la solution (conception). Lorsque la conception se réalise, montrer les limites. Interfaces ? Reprenons de la hauteur ! Quel est le réel problème ? LE CHANGEMENT !

LA VRAIE question porte donc sur ce qui change : Nom : Sssssssss Type : Comportement But : 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)

Nom : Stratégie (Strategy) Type : Comportement But : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. etc. Cancan

Nom : Stratégie (Strategy) Type : Comportement But : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. Exemple de stratégie

Nom : Stratégie (Strategy) Type : Comportement But : Encapsuler les comportements susceptible de changer, afin de les rendre interchangeables. Exemple de Contexte

Nom : Stratégie (Strategy) Type : Comportement But : 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)...

Nom : Stratégie (Strategy) Type : Comportement But : 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...

Le pattern Aaaaaaa

Nom : Aaaaaaa Type : Structural But : 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

Nom : Aaaaaaa Type : Structural But : 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é ?

Nom : Aaaaaaa Type : Structural But : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Petit rappel... La classe Duck, et les strategies de comportement...

Nom : Aaaaaaa Type : Structural But : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Petit rappel... La classe Duck, et les strategies de comportement...

Nom : Aaaaaaa Type : Structural But : 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...

Nom : Aaaaaaa Type : Structural But : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. VS Quelles solutions pourraient apporter une solution simple, rapide... et maintenable ?

Nom : Aaaaaaa Type : Structural But : 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 ?

Nom : Adaptateur (Adapter) Type : Structural But : 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

Nom : Aaaaaaa Type : Structural But : 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 ?

Nom : Adaptateur (Adapter) Type : Structural But : 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

Nom : Adaptateur (Adapter) Type : Structural But : 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é !

Nom : Adaptateur (Adapter) Type : Structural But : 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)

Attention : un canard peut masquer une dinde... Nom : Adaptateur (Adapter) Type : Structural But : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Utilisation... 2 3 1 Attention : un canard peut masquer une dinde...

Nom : Adaptateur (Adapter) Type : Structural But : Permettre à deux instances de classes d'interagir entre elles, sans modification de structure. Un oeil dans le code ? une démo ?

Nom : Adaptateur (Adapter) Type : Structural But : 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 de cette implémentation ...? Adaptateur .net - COM, Adaptateur entre dll third party et main app, Fonctionnement des add ons, Hors informatique ? des adaptateurs de prise UK - FR, les réducteurs de wc pour enfants, les réducteur pour dock d’ipod etc.

Nom : Adaptateur (Adapter) Type : Structural But : 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 ! Privilégier le couplage faible favorise l’é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 !

Le pattern eeeeeeee

Nom : Eeeeeeee Type : Creational But : Centraliser l’instanciation d’objets. Jusque là, pour instancier des objets nous placions des new là où nous en avions besoin... Et où est le problème ? Techniquement, nulle part... mais en ce qui concerne la gestion du changement il s’agit d’une autre affaire !

Le couplage est donc faible. Nom : Eeeeeeee Type : Creational But : 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.

Nom : Eeeeeeee Type : Creational But : 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.

Nom : Eeeeeeee Type : Creational But : Centraliser l’instanciation d’objets. Comment éviter le coté obscure ? Identifier ce qui change et L’externaliser ! souvenez vous des patterns stratégie et adapteur... PS : Cette règle vaut pour tous les patterns...

Nom : Eeeeeeee Type : Creational But : 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

Nom : Eeeeeeee Type : Creational But : Centraliser l’instanciation d’objets. En tant pour bon concepteur, comment aller vous mettre en oeuvre cette application de pizza ?

J’en ai l’eau à la bouche ! Nom : Eeeeeeee Type : Creational But : 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 J’en ai l’eau à la bouche !

Nom : Eeeeeeee Type : Creational But : 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...

Nom : Eeeeeeee Type : Creational But : 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 ?

Nom : Fabrique (Factory) Type : Creational But : Centraliser l’instanciation d’objets. La solution : La notion de fabrique et le pattern « fabrique abstraite »

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émentation de la fabrique Implémentation des pizzas sur base des contrats Pizza 4 froms 4 froms FR 4 froms DE

Nom : Fabrique (Factory) Type : Creational Une dernière notion : le client consomme la «bonne fabrique abstraite» via une méthode « fabrique » consomme

Nom : Fabrique (Factory) Type : Creational Un oeil dans le code ? une démo ?

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...

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

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 (int passengers) public Vehicle (int passengers, int horsePower) public Vehicle (int wheels, bool trailer) public Vehicle (string type)

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 Vehicle CreateCar (int passengers) public Vehicle CreateSuv (int passengers, int horsePower) public Vehicle CreateTruck (int wheels, bool trailer) public Vehicle CreateBoat () public Vehicle CreateBike ()

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.

Nom : Fabrique (Factory) Type : Creational Encapsuler ce qui change est un gage d’évolution ! 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... 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 !