REFACTORING VERS
LES DESIGN
PATTERNS
Améliorer son
architecture
par les design
patterns
 Design est non-déterministe
 Ce n’est pas un processus répétable qui garanti un résultat
prédictible
 Les techniques de design sont guidé par des heuristiques
 Intuitive
 Plusieurs facteurs l’influence
 Le design est un processus itératif
 Processus à évolution lente
 Compromis et priorités
 Principe d’essais et erreurs
LES DÉFIS DU DESIGN
 Abstraction claire
 Designer de façon modulaire
 Favoriser une forte cohésion
 Séparation des préoccupations
 Designer en strate ou en oignons
 Limiter le nombre d’abstractions par niveau
 Distribution des responsabilités balancée
 S’inspirer des objets de la vie
 Limitation du couplage
 Garder le minimum d’interconnections
 Rendre les contrats explicites
 Encapsuler les détails d’implémentation
LES HEURISTIQUES FONDAMENTALES
 Choix de solutions simples
 Pas de partie en trop (utiliser le TDD)
 Éviter les défaillances
 Design pour la testabilité
 Identification des zones à haut risque de changement
 Extensibilité, Plugins, IOC, DI
 Utilisation de solutions éprouvées
 Design Patterns
LES HEURISTIQUES FONDAMENTALES
Contexte
DESIGN PATTERNS(PATRONS DE CONCEPTION)
Problèmes
connus
Bonnes
pratiques
Solutions
éprouvées
Creational
•Factory Method
•Abstract Factory
•Prototype
•Singleton
Structural
•Adapter
•Adapter
•Bridge
•Composite
•Decorator
•Facade
•Proxy
Behavioral
•Interpreter
•Template
Method
•Chain of
responsibility
•Command
•Iterator
•Mediator
•Memento
•Flyweight
•Observer
•State
•Strategy
•Visitor
LES DESIGN PATTERNS
Class
Object
DemoÉTAT INITIAL
PROBLÈME
Extensibilité
Dans ce patron une famille d'algorithmes sont encapsulés de
manière à être interchangeables. Les algorithmes peuvent
changer indépendamment de l'application qui s'en sert.
UTILISER UNE STRATÉGIE INTERCHANGER UN
ALGORITHME
Dans ce patron une famille d'algorithmes sont encapsulés de
manière à être interchangeables. Les algorithmes peuvent
changer indépendamment de l'application qui s'en sert.
UTILISER UNE STRATÉGIE INTERCHANGER UN
ALGORITHME
Demo
UTILISATION DU
STRATEGY PATTERN
PROBLÈME
Fonctionnalités
transversales
Ce patron permet d'attacher dynamiquement des
responsabilités à un objet. C’est une alternative à l'héritage
UTILISER LE DÉCORATEUR POUR ÉVITER L’EXPLOSION
DE HIÉRARCHIE
Ce patron permet d'attacher dynamiquement des
responsabilités à un objet. C’est une alternative à l'héritage
UTILISER LE DÉCORATEUR POUR ÉVITER L’EXPLOSION
DE HIÉRARCHIE
Demo
UTILISATION DU
DECORATOR
PATTERN
PROBLÈME
Construction
complexe d’objets
Ce patron fournit une interface pour créer des objets sans
spécifier la classe concrète. La méthode s’occupe de la
création de l’instance.
UTILISER UNE FACTORY POUR DÉLÉGUER LA CRÉATION
D’OBJETS
Ce patron fournit une interface pour créer des objets sans
spécifier la classe concrète. La méthode s’occupe de la
création de l’instance.
UTILISER UNE FACTORY METHOD POUR DÉLÉGUER LA
CRÉATION D’OBJETS
Demo
UTILISATION DU
FACTORY PATTERN
0
1
0 1 2 3 4 5 6
Locale
COMPLEXITÉComplexité
Niveaux d’abstraction
0
1
0 1 2 3 4 5 6
Locale
Globale
COMPLEXITÉComplexité
Niveaux d’abstraction
Zone de confort
 A retenir
 Le design est un art plus qu’une science
 Les patterns sont là pour nous aider
 Faire attention à la complexité
 Eric De Carufel
 eric@decarufel.net
 http://blog.decarufel.net
 http://pyxis-tech.com
 Sources : https://bitbucket.org/decarufe/refactortopatterns
 Questions?
23
CONCLUSION
Est à la recherche de dévelopeurs
Visitez la section carrière sur
pyxis-tech.com

Refactoring vers les design patterns pyxis v2

  • 1.
    REFACTORING VERS LES DESIGN PATTERNS Améliorerson architecture par les design patterns
  • 2.
     Design estnon-déterministe  Ce n’est pas un processus répétable qui garanti un résultat prédictible  Les techniques de design sont guidé par des heuristiques  Intuitive  Plusieurs facteurs l’influence  Le design est un processus itératif  Processus à évolution lente  Compromis et priorités  Principe d’essais et erreurs LES DÉFIS DU DESIGN
  • 3.
     Abstraction claire Designer de façon modulaire  Favoriser une forte cohésion  Séparation des préoccupations  Designer en strate ou en oignons  Limiter le nombre d’abstractions par niveau  Distribution des responsabilités balancée  S’inspirer des objets de la vie  Limitation du couplage  Garder le minimum d’interconnections  Rendre les contrats explicites  Encapsuler les détails d’implémentation LES HEURISTIQUES FONDAMENTALES
  • 4.
     Choix desolutions simples  Pas de partie en trop (utiliser le TDD)  Éviter les défaillances  Design pour la testabilité  Identification des zones à haut risque de changement  Extensibilité, Plugins, IOC, DI  Utilisation de solutions éprouvées  Design Patterns LES HEURISTIQUES FONDAMENTALES
  • 5.
    Contexte DESIGN PATTERNS(PATRONS DECONCEPTION) Problèmes connus Bonnes pratiques Solutions éprouvées
  • 6.
    Creational •Factory Method •Abstract Factory •Prototype •Singleton Structural •Adapter •Adapter •Bridge •Composite •Decorator •Facade •Proxy Behavioral •Interpreter •Template Method •Chainof responsibility •Command •Iterator •Mediator •Memento •Flyweight •Observer •State •Strategy •Visitor LES DESIGN PATTERNS Class Object
  • 7.
  • 8.
  • 9.
    Dans ce patronune famille d'algorithmes sont encapsulés de manière à être interchangeables. Les algorithmes peuvent changer indépendamment de l'application qui s'en sert. UTILISER UNE STRATÉGIE INTERCHANGER UN ALGORITHME
  • 10.
    Dans ce patronune famille d'algorithmes sont encapsulés de manière à être interchangeables. Les algorithmes peuvent changer indépendamment de l'application qui s'en sert. UTILISER UNE STRATÉGIE INTERCHANGER UN ALGORITHME
  • 11.
  • 12.
  • 13.
    Ce patron permetd'attacher dynamiquement des responsabilités à un objet. C’est une alternative à l'héritage UTILISER LE DÉCORATEUR POUR ÉVITER L’EXPLOSION DE HIÉRARCHIE
  • 14.
    Ce patron permetd'attacher dynamiquement des responsabilités à un objet. C’est une alternative à l'héritage UTILISER LE DÉCORATEUR POUR ÉVITER L’EXPLOSION DE HIÉRARCHIE
  • 15.
  • 16.
  • 17.
    Ce patron fournitune interface pour créer des objets sans spécifier la classe concrète. La méthode s’occupe de la création de l’instance. UTILISER UNE FACTORY POUR DÉLÉGUER LA CRÉATION D’OBJETS
  • 18.
    Ce patron fournitune interface pour créer des objets sans spécifier la classe concrète. La méthode s’occupe de la création de l’instance. UTILISER UNE FACTORY METHOD POUR DÉLÉGUER LA CRÉATION D’OBJETS
  • 19.
  • 20.
    0 1 0 1 23 4 5 6 Locale COMPLEXITÉComplexité Niveaux d’abstraction
  • 21.
    0 1 0 1 23 4 5 6 Locale Globale COMPLEXITÉComplexité Niveaux d’abstraction Zone de confort
  • 22.
     A retenir Le design est un art plus qu’une science  Les patterns sont là pour nous aider  Faire attention à la complexité  Eric De Carufel  eric@decarufel.net  http://blog.decarufel.net  http://pyxis-tech.com  Sources : https://bitbucket.org/decarufe/refactortopatterns  Questions? 23 CONCLUSION Est à la recherche de dévelopeurs Visitez la section carrière sur pyxis-tech.com