1 / 15

Designs Patterns

Designs Patterns. comment rendre son code faiblement couplé, et maintenable. 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… .

hana
Download Presentation

Designs Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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

More Related