designs patterns comment rendre son code faiblement couplé, et maintenable

Designs Patternscomment rendre son code faiblement couplé,

et maintenable...

Pourquoi réinventer la roue, alors que nos douleurs quotidiennes ont été étudiées par d’autres avant nous ?

Par masochisme ? Par sadisme ?

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…

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

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

Etape 3L’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. Exercice :

Etape 1Un client désire une FPS de canards...Un canard a un nom, peut nager, cancaner et doit être affiché.Etape 2Lors 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 !.

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 ?

Héritage ?Interfaces ?

Reprenons de la hauteur !Quel est le réel problème ?

Que proposez vous comme solutions ?

LE CHANGEMENT !

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 : Sssssssss

Type : Comportement


Nom : Stratégie (Strategy)Type : Comportement


Cancan

etc.



Exemple de stratégie



Exemple de Contexte



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

Privilégier le couplage faible favorise l’évolution...

Il est préférable

d’implémenter des

interfaces !

Retour sur les brèves de comptoir ...

L’héritage est un concept

qui s’applique au modèle

métier (le plus souvent).

Encapsuler ce qui change est un gage d’évolution !

Un code doit être ouvert au changement, mais

fermé aux modifications...

La composition est

préférable à l’héritage !



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


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


Il est préférable


interfaces !








La composition est


Nom : Aaaaaaa

Type : Structural


Quelles solutions pourraient apporter une solution simple, rapide... et

maintenable ?

VS

Nom : Aaaaaaa

Type : Structural


Cela jacasse dur autour de ce concept !

Mais en termes d’implémentation cela donne quoi ?

Nom : Adaptateur (Adapter)Type : Structural


IHM gérant exclusivement des

canards...

Interface de canards...

Adaptateur canards-dinde Dinde

Nom : Aaaaaaa

Type : Structural


Revenons à nos mouton...ou plutot à nos canards, et dindes...

En sachant ce que vous savez, quelle serait l’application du pattern Adapter ?



Solution = 3 adaptateurs :

- Adaptateur de comportement de nage,- Adaptateur de comportement Quack,- Adaptateur permettant de transformer une dinde en canard



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é !



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)



Utilisation...

12 3

Attention : un canard

peut masquer une dinde...



Un oeil dans le code ? une démo ?


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

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




Il est préférable


interfaces !







fermé aux modifications...La composition est


Ce n’est ni à la classe métier, ni au contexte à

devoir s’adapter...

Le pattern eeeeeeee

Nom : EeeeeeeeType : Creational

But : Centraliser l’instanciation d’objets.

Et où est le problème ?

Techniquement, nulle part... mais en ce qui concerne la gestion du

changementil s’agit d’une autre affaire !

Jusque là, pour instancier des objets nous placions des new là où nous en avions besoin...


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.



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.



Comment éviter le coté obscure ?

Identifier ce qui changeet

L’externaliser !

souvenez vous des patterns stratégie et adapteur...

PS : Cette règle vaut pour tous les patterns...



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



En tant pour bon concepteur, comment aller vous mettre en

oeuvre cette application de pizza ?



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 !

Evolution :



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

Scoop : Une nouvelle évolution pointe le bout de son nez :



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


La solution : La notion de fabrique et le pattern « fabrique abstraite »

Nom : Fabrique simple (Factory)Type : Creational

App pizzeria

Pizza napolitaine

Pizza 4 froms

4 fromsFR

4 fromsDE

Fabrique pizza

fabrique Fr fabrique DE

NapoFR

NapoDE

Contrat : Interface ou classe abstraite (italique)

Contrat : Interface ou classe abstraite (italique)

Implémentation

de la fabrique

Implémentationdes pizzas sur base des contrats


Une dernière notion : le client consomme la «bonne fabrique abstraite» via une méthode «

fabrique »

consomme

Un oeil dans le code ? une démo ?


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



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



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)



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 ()



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.


Il est préférable


interfaces !


Les interfaces sont des

contrats remplis par

certaines instances, et

consommés par d’autres




Les composants applicatifs consomment les instances, mais ne sont pas responsables de leur instanciation


Centraliser les créations d’instances favorise la

dissociation entre modèle et comportement.

Le « new » n’est pas si anodin que cela !

designs patterns comment rendre son code faiblement couplé, et maintenable

Documents