Architecture Logicielle & Design Patterns PDF

Architecture Logiciel & Design Patterns Pr. AISSAM JADLI Google Classroom [email protected] https://linkedin.com/in/jadliaissam Rappel...

Architecture Logiciel & Design Patterns Pr. AISSAM JADLI Google Classroom [email protected] https://linkedin.com/in/jadliaissam Rappels : Exigences d’un projet informatique Exigences fonc,onnelles: Une applica,on est créée pour répondre, tout d’abord, aux besoins fonc,onnels de l’entreprises. Exigences Techniques ( non-fonc,onnelles) : Ø Les performances Ø La maintenance Ø Sécurité Ø Portabilité Ø Distribu,on Ø Architectures orientées services et haute disponibilité Ø Capacité de fournir le service à différents type de clients (Desktop, Mobile, hNp...) Exigence financières 10/1/24 2 Rappels : Constat Il est très difficile de développer un système logiciel qui respecte ces exigences sans u&liser l’expérience des autres : Réu:liser des modèles de concep:ons (Design Pa?erns) Bâ:r les applica:ons sur des architectures existantes( Architecture JEE, Architecture Dot Net, …etc) Ces architectures offrent des : v Frameworks qui perme?ent de sa:sfaire les exigences techniques: ü Framework pour l’Inversion de contrôle ü Gérer le cycle de vie des composants de l’applica:on ü Séparer le code mé:er du code technique ü Framework ORM (Mapping Objet Rela:onnel) ü Framework MVC WEB v Middlewares pour faire communiquer les composants distribués de l’applica:on 10/1/24 3 Rappels : Concepts fondamentaux de l’orienté Objet v Classe v Objet v Héritage v Encapsula4on v Polymorphisme 10/1/24 4 Rappels : Pourquoi l’approche Orientée Objet a été créée ? 10/1/24 5 Rappels : Héritage et composition 10/1/24 6 Définition et présentation des partons logiciels v Un patron décrit (et nomme) une solu4on à un problème Commun Ø Offre une solu4on abstraite pour faciliter la réu4lisa4on Ø Est formulé en termes de classes et d’objets Ø Peut être implémenté différemment en fonc4on du langage de programma4on u4lisé v La solu4on proposée par un patron peut être modifiée ou adaptée selon les besoins du logiciel Ø « Forcer » l’u4lisa4on d’un patron dans un logiciel est une mauvaise pra4que de Référence de base de ce cours développement 10/1/24 7 Définition et présentation des partons logiciels 10/1/24 8 Définition et présentation des partons logiciels v Les design pa*erns (patrons de concep.on) décrivent des procédés généraux et réu.lisables pour concevoir des logiciels v Un design pa*ern décrit une bonne pra.que et une solu.on standard en réponse à un problème de concep.on d'un logiciel 10/1/24 9 Définition et présentation des partons logiciels A noter que Les design pa*erns me?ent en œuvre les principes SOLID. 10/1/24 10 Caractéristiques des patrons logiciels Les caractéris.ques des patrons logiciels incluent : 1) Abstrac*on : Les patrons de concep.on sont des abstrac.ons qui perme?ent de résoudre des problèmes de concep.on complexes en décrivant des rela.ons et des interac.ons entre les différents éléments du système. 2) Réu*lisabilité : Les patrons de concep.on sont des solu.ons réu.lisables qui ont été testées et éprouvées dans des situa.ons similaires, ce qui permet de gagner du temps et d'éviter de réinventer la roue à chaque fois. 3) Indépendance du langage : Les patrons de concep.on sont des solu.ons génériques qui peuvent être implémentées dans n'importe quel langage de programma.on. 10/1/24 11  Design Patterns: Patrons Caractéristiques des patrons logiciels de conception 4) Documenta*on : Les patrons de concep.on sont bien documentés et ont des noms clairs qui facilitent leur iden.fica.on et leur u.lisa.on. 5) Standardisa*on : Les patrons de concep.on sont devenus un standard dans l'industrie des logiciels, ce qui facilite leur compréhension et leur adop.on par les développeurs. 6) Flexibilité : Les patrons de concep.on sont conçus pour être flexibles et s'adapter à différentes situa.ons, ce qui permet de les u.liser dans une variété de contextes différents. 7) Cohérence : Les patrons de concep.on favorisent la cohérence et la modularité du code en fournissant des structures de concep.on claires et bien définies. 10/1/24 12 Classification Design et utilités Pa1erns: des patrons Patrons logiciels de concep2on Les patrons de concep.on peuvent être classés en trois grandes catégories : Les patrons de créa.on Les patrons de structure Les patrons de comportement 10/1/24 13 Classification et utilités des patrons logiciels v Comportement (organiser la collabora2on entre objets) § Décrivent les modèles de communica3on et interac3on entres les objets § Ges3on des interac3ons dynamiques entre des classes et des objets Patrons: Observateur, Stratégie, Commande, Médiateur, Chaîne de responsabilité, …etc. v Créa2on (créer des objets) § Descrip3on de la manière dont un objet ou un ensemble d'objets peuvent être créés, ini3alisés, et configurés § Isola3on du code rela3f à la créa3on, à l'ini3alisa3on afin de rendre l'applica3on indépendante de ces aspects § Définir l’abstrac3on du processus d’instancia3on afin de rendre un système indépendant de la façon dont ses objets sont créés et représentés Patrons: Fabrique, Fabrique abstraite, Prototype, Singleton, …etc. 10/1/24 14 Classification et utilités des patrons logiciels v Structure (organiser les classes) § Se concentrent sur la façon dont les classes et les objets sont composés pour obtenir de plus grandes structures § Description de la manière dont doivent être connectés des objets de l'application afin de rendre ces connections indépendantes des évolutions futures de l'application. Patrons: Décorateur, Adapteur, Façade, Pont, Objet composite, Poids-mouche, Proxy 10/1/24 15 Avantages v Réu.lisabilité : Solu.ons éprouvées à des problèmes récurrents v Communica.on facilitée : Vocabulaire commun entre développeurs v Évolu.vité : Structures flexibles pour les changements futurs v Qualité : Meilleures pra.ques qui améliorent la concep.on globale v Maintenabilité : Les design pa?erns favorisent une structure de code organisée et cohérente, facilitant la maintenance à long terme. v Scalabilité : Certains pa?erns comme le Singleton ou le Factory method facilitent la ges.on des ressources dans les applica.ons à grande échelle. 10/1/24 16 Inconvénients v Complexité accrue : Peut compliquer inutilement des problèmes simples v Sur-Engineering : Risque d'appliquer des patterns sans réelle nécessité v Courbe d'apprentissage : Temps nécessaire pour maîtriser les différents patterns v Difficulté de choix : Avec de nombreux patterns disponibles, il peut être difficile de choisir le plus approprié pour une situation donnée. v Incompréhension : Une mauvaise compréhension ou application d'un pattern peut conduire à des problèmes de conception plus importants que ceux qu'il était censé résoudre. 10/1/24 17 Tester vos Connaissances Pr. JADLI AISSAM 18 Plan du Cours Strategy Decorator Observer State Singleton Factory 10/1/24 19 Design Pa*erns : Strategy Joël travaille pour une société qui a rencontré un énorme succès avec un jeu de simulation de mare aux canards, SuperCanard. Le jeu affiche toutes les sortes de canards qui nagent et émettent des sons. Les premiers concepteurs du système ont utilisé une superclasse Canard dont tous les autres types de canards héritent. 10/1/24 20  Patron de conception Design Pa*erns : Strategy Stratégie 10/2/24 21  Patron de conception Design Pa*erns : Strategy Stratégie v A une année donné, la société a subi de plus de pression de la part de la concurrence. v Pour battre cette concurrence, il faut une idée géniale: les canards volants 10/2/24 22  Patron de conception Design Pa*erns : Strategy Stratégie 10/2/24 23  Patron de conception Design Pa*erns : Strategy Stratégie v A la réunion de démonstra4on en présence des ac4onnaires, Il y a plein de canards en plas4que qui volent 10/2/24 24  Patron de conception Design Patterns : Strategy Stratégie v Une mise à jour locale du code a provoqué un effet de bord global (des canards en plas4que qui volent)! 10/2/24 25  Patron de conception Design Pa*erns : Strategy Stratégie vJoël réfléchit à l’héritage ? 10/2/24 26 Patron de conception Design Pa*erns : Strategy Stratégie v Les dirigeants ont décidé de réactualiser le produit tous les six mois. v Joël s’est rendu compte que l’héritage n’était pas probablement la bonne réponse. 10/2/24 27  Patron de conception Design Pa*erns : Strategy Stratégie v Il doit modifier le comportement de vol dans les 48 sous classes de canard qui volent vCréer des sous-classes qui implémentent l’interface volant ou cancaneur résout une par;e de problème mais détruit la réu,lisabilité du code de ces comportements. Un vrai cauchemar au plan de la maintenance vIl y a des parties de code qui seront recopiées plusieurs fois dans des sous classes. Par exemple le code de la version de « voler avec des ailles » sera recopié dans toutes les sous classes canard ayant des ailles ! s’il y a un changement dans ce code alors il faut aller le modifier dans toutes ces sous classes !!! v La seule constante entre tous le projet de développement de logiciel c’est LE CHANGEMENT v Une application qui n’évoluera pas au fil du temps, mourra. 10/2/24 28  Patron de conception Design Pa*erns : Strategy Stratégie Principe de conception Identifier les aspects de votre application qui varient et Principe séparez-les de ceux qui demeurent constants vExtraire les parties variables et les encapsuler vous permettra plus tard de les modifier ou de les augmenter sans affecter celles qui ne varient pas v Tous les patterns fournissent un moyen de permettre à une partie d’un système de varier indépendamment de toutes les autres 10/2/24 29  Patron de conception Design Pa*erns : Strategy Stratégie v Appliquons ce principe au problème de superCanard! 10/2/24 30  Patron de conception Design Pa*erns : Strategy Stratégie v Comment allons-nous procéder pour concevoir les classes qui implémentent les deux types de comportement? ü Nous voulons affecter des comportements aux instances des classes Canard. ü Modifier le comportement d’un canard dynamiquement avec les méthodes set. ( pouvoir modifier la façon de voler du canard au moment de l’exécuCon) Principe de conception Programmer une interface, non une implémentation Principe 10/2/24 31  Patron de conception Design Pa*erns : Strategy Stratégie v Appliquons ce deuxième principe de conception ü Les comportements de Canard résideront dans une classe disCncte – une classe qui Implémente une interface comportementale parCculière ü Les classes Canard n’auront besoin de connaitre aucun détail de l’implémentaCon de leur propre comportement. 10/2/24 32  Patron de conception Design Pa*erns : Strategy Stratégie v Implémenter les comportements des canards Les autres types d’objets peuvent réutiliser nos comportements de vol et de cancaner On peut ajouter de nouveaux comportements sans modifier aucune des classes comportementales existantes 10/2/24 33  Patron de conception Design Patterns : Strategy Stratégie v Intégrer les comportements des canards Un canard va déléguer ses comportements au lieu d’u9liser les méthodes voler() et cancaner() définies dans la classes canard ou ( une sous classes) 10/2/24 34  Patron de conception Design Pa*erns : Strategy Stratégie v Diagramme de classes 10/2/24 35  Patron de conception Design Pa*erns : Strategy Stratégie v Diagramme de classes : Cas Général 10/2/24 36  Patron de conception Design Patterns : Strategy Stratégie Principe de conception Principe Préférez la composition à l’héritage vCréer des systèmes en u.lisant la composi.on procure beaucoup plus de souplesse. v Il ne permet non seulement d’encapsuler une famille d’algorithmes, mais encore de modifier le comportement au moment de l’exécu.on tant que l’objet avec lequel il est composé implémente la bonne interface comportementale. 10/2/24 37