Maitriser la POO & les design pattern

Maitriser la POO & les design pattern

La Programmation Orientée Object (POO) va au-delà de la conception de classes et d’interfaces. Elle inclut une grande variété de concepts tels que les objets, les entités, les "value objects", les services, les modèles de conception, les principes SOLID, LoD (Law of Demeter), le couplage, etc. Maîtriser la POO nécessite souvent plusieurs années d’expérience, une grande dose de persévérance et de remise en question.

Cette présentation aura pour but de faire la lumière sur les concepts de base de l’approche OOP, qui sont une des conditions requises pour l’appréhension des concepts avancés tels que l’utilisation des modèles de conception (design pattern) ou la mise en œuvre d’architecture moderne (CQRS, DDD). Nous conclurons sur l’utilité des design pattern dans un contexte moderne de développement orienté objet.

Cette présentation sera découpée en cinq parties :

1/ Concept de base OOP (~5mn)
Ici nous rafraichirons les mémoires sur les bases de l’OOP. Nous parlerons de ce qui compose un objet, une classe et reverrons la notion de hiérarchie des objets.

2/ Les piliers OOP (~20mn)
Nous parcourrons et définirons les quatre piliers du “paradigme objet”. Nous les expliquerons, ce qui sera une étape clef dans la compréhension des design patterns et des grands principes OOP.

3/ Design Pattern qu’est-ce que c’est ? (~5mn)
Nous allons sur cette partie parler des design pattern et expliquer ce que c’est et à quoi ils consistent. Il y aura en outre une présentation des différentes familles de design pattern et leurs descriptions.

5/ Design Pattern, pourquoi je devrais les apprendre ? (~5mn)
C’est la chute de la présentation, tous ont déjà entendu parler de ces design pattern parfois peut-être sans connaitre les motivations de son existence. Ici nous allons donc donner deux arguments qui devraient motiver tous les développeurs à passer du temps sur ce sujet et à essayer de les apprendre.

Et une slide bonus...

Afin de pouvoir respecter le format de présentation du camp, nous parlerons sans nous attarder des principes SOLID. Si vous souhaitez approfondir la question, contactez-moi pour qu'on organise une session de BoF.

1d6f182c2fc594308657e7f3f335d19d?s=128

Alexandre Mallet

February 15, 2019
Tweet

Transcript

  1. 1.

    1 MADISON COMPANY Y O U C A N W

    R I T E H E R E A company is an association or collection of individuals, whether natural persons, legal persons, or a mixture of both. Company members share a common purpose and unite in order to focus their various. Maîtriser la POO & les Design Patterns
  2. 2.

    2 Les secrets des design patterns here. D e s

    i g n P a t t e r n s : q u ’ e s t - c e q u e c ’ e s t ? Après tout pourquoi oui… D e s i g n P a t t e r n s : p o u r q u o i l e s a p p r e n d r e ? Table des matières M a î t r i s e r l a P O O & l e s D e s i g n P a t t e r n s Moi en une phrase ou deux ou trois… M e La vraie nouveauté naît toujours dans le retour aux sources. C o n c e p t d e b a s e La programmation orienté objet est basé sur 4 piliers, nous les parcourrons. L e s p i l i e r s O O P
  3. 3.

    3 Clean code addict, Craftsman, Architect at IAD International, référent

    PHP et consultant Neolynk. A l e x a n d r e M A L L E T @ w o p r r r We b A r c h i t e c t Me M a î t r i s e r l a P O O & l e s D e s i g n P a t t e r n s
  4. 4.

    4 Concept de base M a î t r i

    s e r l a P O O & l e s D e s i g n P a t t e r n s Paradigme basé sur un concept de « conteneur de données et de comportement liées a ses données » Ses conteneurs existent sous la forme de « paquets » spéciaux appelé « objets » Les objets sont construits à partir d’un ensemble de « plans » définit par le programmeur appelé « classes »
  5. 5.

    5 Objets et classes M a î t r i

    s e r l a P O O & l e s D e s i g n P a t t e r n s Ceci est un diagramme de classe UML. Vous en croiserez tout au long de la présentation et durant toute votre vie de developpeur. + breathe() + eat(food) + run(destination) + sleep(hours) + meow() Cat + name + gender + age + weight + color … Nom Méthodes Champs (attributs) Visibilité + = pubic - = private # = protected Ellipsis signifie qu’il y a d’autres choses dans la classe, mais ce n’est pas important pour le moment
  6. 6.

    6 Objets et classes M a î t r i

    s e r l a P O O & l e s D e s i g n P a t t e r n s name = Kins sex = male age = 3 weight = 7 color = brown Kins : Cat name = Jane sex = female age = 2 weight = 5 color = gray Jane : Cat Les méthodes d’un objet définissent le comportement Les attributs d’un objet sont souvent référencés comme étant l’état d’un l’objet Un objet est une instance d’une classe
  7. 7.

    7 Hiérarchie des classes M a î t r i

    s e r l a P O O & l e s D e s i g n P a t t e r n s + breathe() + eat(food) + run(destination) + sleep(hours) Animal + name + gender + age + weight + color … + meow() Cat - isNasty: bool + woof() Dog - bestFriend: Human … Superclass Sous-classes Une flèche avec un triangle vide indique l’héritage et passe toujours d’une sous- classe vers la superclass. Ici pour l’exemple, les méthodes ‘Meow()’ et ‘Woof()’ ne sont pas optimales, mais cette notion sera plus précisément expliquée avec le pilier du POLYMORPHISME.
  8. 8.

    8 Hiérarchie des classes M a î t r i

    s e r l a P O O & l e s D e s i g n P a t t e r n s Cat Dog Animal Plant Organism Un diagramme UML peut être simplifié s’il est plus important de montrer les rapports entre les différentes classes.
  9. 9.

    9 Les piliers de la POO M a î t

    r i s e r l a P O O & l e s D e s i g n P a t t e r n s POO A B S T R A C T I O N E N C A P S U L AT I O N H E R I TA G E P O LY M O R P H I S M E
  10. 10.

    10 Les piliers de la POO M a î t

    r i s e r l a P O O & l e s D e s i g n P a t t e r n s La classe AIRPLAINE vu sur deux contextes différent pour le même objet du monde réel. + fly() Airplane - speed - altitude - axe - angle … + reserveSeats(n) Airplane - seats … A B S T R A C T I O N
  11. 11.

    E N C A P S U L AT I

    O N 11 Les piliers de la POO M a î t r i s e r l a P O O & l e s D e s i g n P a t t e r n s + accept(vehicle : FlyingTransport) Airport … … + fly(origin, destination, passengers) <<interface>> FlyingTransport + fly(origin, destination, passengers) Helicopter … … + fly(origin, destination, passengers) Airplane … … + fly(origin, destination, passengers) DomesticatedDragon … … Une simple flèche désigne une dépendance de la classe vers une autre. Les interfaces en UML ressemble fortement aux classes, mais elle n’ont que des méthodes clairement affichées. Une flèche avec un triangle vide précédé de lignes en pointillées signifie que la classe implémente une ou plusieurs interfaces. De nouveau ici la méthode ‘fly()’ est implémentée de cette façon pour servir la compréhension du propos. Dans un cadre normal et optimisé la méthode ‘fly()’ n’aurait et ne devrait pas avoir à manipuler trois paramètres.
  12. 12.

    H E R I TA G E 12 Les piliers

    de la POO M a î t r i s e r l a P O O & l e s D e s i g n P a t t e r n s Cat Mammal Animal + run(destination) <<interface>> FourLegged + breath() <<interface>> OxygenBreather Diagramme UML d'extension d'une seule classe par rapport à l'implémentation de plusieurs interfaces en même temps. + move(destination) <<interface>> Movable
  13. 13.

    + breathe() + eat(food) + run(destination) + sleep(hours) Animal +

    name + gender + age + weight + color … + meow() Cat - isNasty: bool + woof() Dog - bestFriend: Human … P O LY M O R P H I S M E 13 Les piliers de la POO M a î t r i s e r l a P O O & l e s D e s i g n P a t t e r n s + makeSound() Animal … … + makeSound() Cat … + makeSound() Dog … + makeSound() Dragon … System.out.print(‘Meow’) System.out.print(‘Woof’) System.out.print(‘Grrrrrrr’) Identifie un commentaire en UML, c’est comme ça que l’on représente les détails d’implémentation pour une classe ou méthode. Le nom des classes et méthodes abstraites sont affichées en italique.
  14. 14.

    14 Design Pattern M a î t r i s

    e r l a P O O & l e s D e s i g n P a t t e r n s Les modèles de conception sont des solutions typiques aux problèmes fréquemment rencontrés lors de la conception de logiciels ou d’applications. Q u ’ e s t - c e q u e c ’ e s t ? Un algorithme est une recette de cuisine avec un détail clair et précis d’actions à mener pour atteindre un objectif. Le design pattern lui est plus une sorte de « Plan » dont vous pourrez voir le résultat et les caractéristiques finales. A l g o r i t h m e V S D e s i g n P a t t e r n Picture : https://refactoring.guru/design-patterns
  15. 15.

    15 Design Pattern: En quoi ça consiste ? M a

    î t r i s e r l a P O O & l e s D e s i g n P a t t e r n s I Intention Description du problème et la solution associée. M Motivation Explique plus en détail le problème et la solution rendue possible par le pattern. S Structure Montre la structure et la liaison des classes du pattern en UML. E Exemple de code Un exemple de code concret du pattern appliqué à un langage de programmation. Design Pattern Schema
  16. 16.

    16 Design Pattern: Classification M a î t r i

    s e r l a P O O & l e s D e s i g n P a t t e r n s Creationals Création Abstract Factory Builder Prototype Singleton Behavioral Comportement Chain of responsibility Strategy Mediator Iterator Structural Structure Decorator Adapter Facade Proxy
  17. 17.

    17 Design Pattern M a î t r i s

    e r l a P O O & l e s D e s i g n P a t t e r n s Je ne vais pas vous mentir, vous pouvez continuer à travailler en tant que programmeur pendant de nombreuses années sans même jamais en avoir implémenté… P o u r q u o i l e s a p p r e n d r e ? • Ils sont une sorte de boite à outil pour programmeur et sont éprouvés depuis plusieurs années comme solution à une problématique précise. D e u x a r g u m e n t s « P o u r » • Il fournit un langage commun entre les différents interlocuteurs programmeurs de langages différents et permet une meilleure compréhension de votre propos.
  18. 18.

    18

  19. 19.

    19 La slide bonus… M a î t r i

    s e r l a P O O & l e s D e s i g n P a t t e r n s S O L I Single Responsibility OPEN / CLOSE LISKOV SUBSTITUTION INTERFACE SEGREGATION D DEPENDENCY INVERSION
  20. 20.

    20 Un peu de lecture M a î t r

    i s e r l a P O O & l e s D e s i g n P a t t e r n s Un site très complet sur le sujet des design patterns (https://sourcemaking.com/design_patterns) Du concret ? Woprrr : En voila :) (https://designpatternsphp.readthedocs.io/en/latest/README.html) Excellente ressource sur le sujet du code propre et du respect des principes (https://medium.com/web- engineering-vox/improving-code-quality-with-object-calisthenics-aa4ad67a61f1) A LIRE ET RELIRE