Révision Les principes SOLID.

Présentation au sujet: "Révision Les principes SOLID."— Transcription de la présentation:

1 Révision Les principes SOLID

2 Question Qu’est-ce que le S de Solid?

3 Responsabilité unique (SRP: Single Responsibility Principle)
Le principe de responsabilité unique, réduit à sa plus simple expression, est qu'une classe donnée ne doit avoir qu'une seule responsabilité, et, par conséquent, qu'elle ne doit avoir qu'une seule raison de changer.

4 Question Qu’est-ce que le O de Solid?

5 Ouvert/fermé (OCP: Open/closed Principle)
Définition: "Les modules qui se conforment au principe ouvert/ferme ont deux attributs principaux. 1 - Ils sont "ouverts pour l'extension". Cela signifie que le comportement du module peut être étendu, que l'on peut faire se comporter ce module de façons nouvelles et différentes si les exigences de l'application sont modifiées, ou pour remplir les besoins d'une autre application. 2 - Ils sont "Fermés à la modification". Le code source d'un tel module ne peut pas être modifié. Personne n'est autorisé à y apporter des modifications.«  Bref, il ne faut pas briser la logique de l’héritage.

6 Question Qu’est-ce que le L de Solid?

7 La substitution de Liskov
Définition: Les sous-types doivent être remplaçables par leur type de base. Là, je vais en voir un ou deux (ou plus) dire: « Oui, mais à partir du moment où ma classe S hérite de ma classe T », je dois pouvoir caster S en T et là ça va marcher... 

8 Question Qu’est-ce que le I de Solid?

9 Séparation des Interfaces (ISP: Interface Segregation Principle)
Définition: Les clients d'une entité logicielle ne doivent pas avoir à dépendre d'une interface qu'ils n'utilisent pas. Ce principe apporte principalement une diminution du couplage entre les classes (les classes ne dépendant plus les unes des autres). L'autre avantage d'ISP est que les clients augmentent en robustesse.

10 Question Qu’est-ce que le D de Solid?

11 Inversion des dépendances (DIP: Dependency Inversion Principle)
Définition: Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.

12 Architecture d’application – Hugo St-Louis Hiver 2017
Les designs pattern Architecture d’application – Hugo St-Louis Hiver 2017

13 Objectifs de la présentation
Comprendre ce qu'est un pattern En connaître les principaux représentants Exemples d'utilisation Des ressources pour aller plus loin

14 Définition d’un design pattern
Modèle de conception parfois aussi « Motifs de conception » ou « Patrons de conception ». Solutions à des problèmes classiques. Indépendants du langage. En informatique, et plus particulièrement en développement logiciel, un patron de conception (en anglais : « design pattern ») est un arrangement caractéristique de modules, reconnu comme bonne pratique en réponse à un problème de conception d’un logiciel. Il décrit une solution standard, utilisable dans la conception de différents logiciels. Un patron de conception est issu de l’expérience des concepteurs de logiciels. Il décrit sous forme de diagrammes un arrangement récurrent de rôles et d’actions joués par des modules d’un logiciel, et le nom du patron sert de vocabulaire commun entre le concepteur et le programmeur. D’une manière analogue à un patron de couture, le patron de conception décrit les grandes lignes d’une solution, qui peuvent ensuite être modifiées et adaptées en fonction des besoins. Les patrons de conception décrivent des procédés de conception généraux et permettent en conséquence de capitaliser l’expérience appliquée à la conception de logiciel. Ils ont une influence sur l’architecture logicielle d’un système informatique. Description Les patrons servent à documenter des bonnes pratiques basées sur l’expérience. Ils sont le résultat d’une synthèse de l’expérience acquise par les ingénieurs. Les patrons spécifient des solutions à des problèmes qui ne peuvent pas être résolus par un composant isolé: La description de la plupart des patrons implique plusieurs rôles qui peuvent être joués par plusieurs composants d’un logiciel. Par exemple le patron Observer implique deux rôles qui sont le sujet et l’observateur. Les patrons apportent un vocabulaire commun entre l’architecte et le programmeur: Si le programmeur connait le patron de conception Observer, alors l’architecte n’aura pas besoin de lui donner de longues explications et le dialogue se limitera à « ici j’ai utilisé un Observer ».

15 Apparition des patterns
Murray Silverstein, Sara Ishikawa,Christopher Alexander, « A Pattern Language: Towns, Buildings, Construction » [1977] « Chaque modèle 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, de telle façon que l'on puisse la réutiliser des millions de fois et ce jamais de la même manière » [AIS+ 77]

16 L'ouvrage de référence GoF « Gang of Four » Design patterns. Elements of reusable ObjectOriented Software [1994] Erich Gamma, Richard Helm, Ralph Johnson John Vlissides

17 Pourquoi les étudier ? Catalogue de solutions qui permettent de bénéficier du savoir-faire d'experts dans des contextes éprouvé. (fiables et robustes) Facilite la conception. Ne pas réinventer la roue. Facilite la communication entre développeurs. Pour résoudre un problème

18 Become a programming ninja
Mais la vraie raison … Become a programming ninja

19 Division des patterns Les patterns sont divisés en 3 groupes: Création
Structure Comportement

20 Les 5 patterns de création
Factory method, AbstractFactory, Builder, Prototype, Singleton Objectifs Abstraction du processus de création. Encapsulation de la logique de création. On ne sait pas à l'avance ce qui sera créé ou comment cela sera créé.

21 Les 7 patterns de structure
Adapter, Bridge, Composite, Decorator, Interface, Flyweight, Proxy Objectifs: Comment sont assemblés les objets. Découpler l'interface de l'implémentation.

22 Les 11 patterns comportementaux
Les patterns de Comportement Interpretor, Template method, Chain of responsability, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor Objectifs: Définir un mode de communication entre les objets

23 Quelques exemples pour commencer
Singleton (Création) Factory method(Création) Observer (Comportement) States (Comportement)

24 [Création] Singleton Problématique : S'assurer qu'il existe une seule instance d'un objet donné pour toute l'application. Solution : Une méthode statique pour contrôler l'instanciation. Rendre ce processus d'instanciation l'unique solution possible pour la classe en question.

25 [Création] Singleton, diagramme

26 [Création] Singleton, pièges & différences
N'est pas une classe statique Une instance à manipuler. Conserve un contexte Peut être passé en paramètre à une méthode N'est pas une variable globale Éviter la singletonite

27 [Création] Singleton, exemple

28 [Création] Singleton, Exercice
Faites un programme qui permet de répartir la charge sur plusieurs serveurs(LoadBalancing). Ce programme retourne une adresse de connexion à tour de rôle à partir d’une liste d’adresse. La classe qui contient(distribue) les adresses doit être un singleton, car l’administrateur peut ajouter/supprimer des adresses en tout temps.

29

30

31 [Création] Factory method
Problématique : Obtenir facilement un objet prêt à l'emploi et qui correspond à nos besoins. Nous voulons encapsuler la logique de fabrication des classes. Solution : Une classe / une méthode qui encapsule la logique de création des objets en question. Ce patron permet d'instancier des objets dont le type est dérivé d'un type abstrait. La classe exacte de l'objet n'est donc pas connue par l'appelant.

32 [Création] Factory Method, diagramme

33 [Création] Factory Method, exemple
Supposons un supermarché qui doit s’approvisionner avec un certain produit. Dépendamment du temps de l’année, le produit proviendra d’un pays différent. Chacun des produits est modélisé sous la forme d’un objet.

34 [Création] Factory Method, Exercice
Dans une usine, plusieurs travailleurs s’efforcent pour accomplir un ensemble de tâches. Les travailleurs travaillent soit de jour (8 h à 16 h), de soir (16 h à 24 h) ou de nuit (24 h à 8 h). Dépendamment du quart de travaillent, les tâches à réaliser sont différentes. Développer un patron de conception de type « factory method » qui permet de créer des travailleurs en fonction de l’heure. Pour chacun des travailleurs, faites une méthode Travailler(…) qui affiche dans la console les tâches qu’ils réalisent.

35 [Comportement] Observer
Problématique : Permettre à un objet de réagir aux comportements d'un autre sans pour autant les lier « en dur ». Solution : Définir un objet comme «observable » et donc capable de notifier des changements à des observateurs, quels qu'ils soient.

36 [Comportement] Observer

37 [Comportement] Observer, Exemple

38 [Comportement] Observer, Exercice
Faite un programme qui permet de notifier tous les objets Etudiant abonner à l’observer lorsqu’il y a une tempête de neige.

39 [Comportement] STATE Problématique : Permettre un comportement différence en fonction d’un contexte(valeur) Solution : Gérer un état qui permet de rediriger le comportement vers la bonne classe.

40 [Comportement] STATE, diagramme

41 [Comportement] STATE, diagramme
Il existe deux variantes du patron state. Une classe mère qui implémente les méthodes alors que les fils (états différents) modifient les propriétés utilisées dans les méthodes. Une classe mère abstraite qui donne les propriétés à utiliser et les signatures de méthodes alors que les fils (états différents) modifient les propriétés et implémentent les méthodes.

42 [Comportement] STATE, Exemple
Nous allons concevoir un programme qui utilise le pattern « state » qui permet à un compte bancaire d’avoir différents état(statut) soit les suivants: RedState Limite du type de compte[-500 $, 0$[; Intérêt annuel : 0% Frais de service pour chaque retrait : 15$ SilverState Limite du type de compte[0$, 1000$[; Frais de service pour chaque retrait : 1$ GoldState Limite du type de compte[1000$, ∞$. Intérêt annuel : 5% Frais de service pour chaque retrait: 0$ Toute transaction doit faire l’objet d’une surveillance

43 [Comportement] STATE, Exercice

44 [Comportement] STATE, Exercice
Vous devez concevoir un programme qui permet de modéliser un combat ultime entre deux guerriers. À tour de rôle, deux guerriers se frappent jusqu’à un combat mortel(>1pdv). Lors de ce combat, le nombre de points de vie(pdv) d’un guerrier influence la façon et l’intensité du combat. C’est-à-dire: Si le guerrier est En Forme(> 50 pdv) Se bat avec une épée et une hache Inflige aléatoirement [10,15] pdv à sont adversaire Lance des Cries de guerre à son adversaire à chaque coup qu’il donne Si le guerrier est Correct ([15,50] pdv) Se bat avec une épée Inflige aléatoirement [5, 10] pdv à sont adversaire Si le guerrier est Magané(<15 pdv) Se bat à main nue Inflige aléatoirement [0,3] pdv à sont adversaire Le guerrier pleure à chaque fois qu’il inflige un coup à son adversaire

45 BONUS! Question du publique:
Si je veux partager une application qui utilise entity framework sans que la personne puisse voir mon mot de passe dans l’APP.config, je fais comment?

46 Bonne question… mais j’ai des contacts.
Et moi de dire ! Bonne question… mais j’ai des contacts.

47 La réponse Un ami spécialiste en sécurité m’a référé vers ce site:

48 Questions? On passe au TP!