Motifs de conception ou “Design Patterns”

1. Motifs de conceptionou “Design Patterns” Laurent Ciarletta @mines.inpl-nancy.fr

2. Bibliographie… • « A System of Pattern » Bushmann et All • « Design Patterns » Gamma et All • « Concurrent Programming in Java » D. Lea. • « Distributed Objects » Orfali et All • « Applying UML and Patterns » Larman • Présentations de Pascal Molli et Yannis Bres

3. Contexte

4. Modélisation d’objets Des objectifs parfois antagonistes : • Encapsuler des données sans en empêcher l’accès • Trouver le bon niveau de granularité des objets • Limiter les dépendances entre objets • Concevoir des objets polyvalents, flexibles, réutilisables • Simplicité d’utilisation • Implémentation performante

5. Modélisation d’applications Modéliser correctement une application : • Processus complexe • Expertise acquise au fil des expériences • Problèmes de conceptions récurrents : des Design Patterns Un (seminal) "livre de recettes" : Design Patterns, Elements of Reusable Object-Oriented Software E. Gamma, R. Helm, R. Johnson, J. Vlissides - Addison Wesley

6. Becoming a Chess Master • First learn rules and physical requirements • e.g., names of pieces, legal movements, chess board geometry and orientation, etc. • Then learn principles • e.g., relative value of certain pieces, strategic value of center squares, power of a threat, etc. • However, to become a master of chess, one must study the games of other masters • These games contain patterns that must be understood, memorized, and applied repeatedly • There are hundreds of these patterns

7. Becoming a Software Designer Master • First learn the rules • e.g., the algorithms, data structures and languages of software • Then learn the principles • e.g., structured programming, modular programming, object oriented programming, generic programming, etc. • However, to truly master software design, one must study the designs of other masters • These designs contain patterns must be understood, memorized, and applied repeatedly • There are hundreds of these patterns

8. Patterns… • « Patterns help you build on the collective experience of skilled software engineers. » • «  They capture existing, well-proven experience in software development and help to promote good design practice » • « Every pattern deals with a specific, recurring problem in the design or implementation of a software system » • « Patterns can be used to construct software architectures with specific properties… »

9. Software Architecture • A software architecture is a description of the subsystems and components of a software system and the relationships between them. • Subsystems and components are typically specified in different views to show the relevant functional and non-functional properties of a software system. • The software system is an artifact. It is the result of the software design activity.

10. Component • A component is an encapsulated part of a software system. A component has an interface. • Components serve as the building blocks for the structure of a system. • At a programming-language level, components may be represented as modules, classes, objects or a set related functions.

11. Subsystems • A subsystem is a set of collaborating components performing a given task. A subsystem is considered a separate entity within a software architecture. • It performs its designated task by interacting with other subsystems and components…

12. Architectural Patterns • An architectural Pattern express a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, their responsibilities, and includes rules and guidelines for organizing the relationships between them.

13. Design patterns • A design pattern provides a scheme for refining the subsystems or components of a software system, or the relation ships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context.

14. Idioms • An Idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

15. Framework • A framework is a partially complete software (sub-) system that is intended to be instantiated. It defines the architecture for a family of (sub-) systems and provides the basic building blocks to create them. It also defines the places where adaptations for specific functionality should be made.

16. Un Design Pattern Nom Exposé du problème Contexte de mise en œuvre, contraintes limitantes Description de la solution proposée Conseils d’implémentation Exemple d’implémentation Conseils d’implémentation Confrontation avec d’autres Design Patterns Modèles parfois (souvent ?) triviaux Relative standardisation du nommage des Design Patterns

17. Principales classes de Design Patterns Patterns de création • Création d’objets sans instanciation directe d’une classe Patterns de composition • Composition de groupes d’objets Patterns comportementaux • Modélisation des communications inter-objets et du flot de données

18. Les Design Patterns

19. Pattern Factory Method • Intent • Define an interface for creating an object, but let sub-classes decide which class to instantiate • let a class defer instantiation to subclasses • Also known as Virtual Constructor

20. Factory Method/Virtual Constructor • Applicability : Use when • a class cannot anticipate the class of objects it must create • a class wants its subclasses to specify the objects it creates

21. Structure

22. Factory method • Consequences • Provide hooks for subclasses • connects parallel class hierarchies • Known uses • MacApp, ET++ • ClassView in smalltalk80 MVC (controller creation) • Orbix ORB for generating PROXY object

23. Abstract Factory Objectif : obtenir des instances de classes implémentant des interfaces connues, mais en ignorant le type réel de la classe obtenue Exemple : une application gérant des documents polymorphes générateur de compo-sants graphiques supportant une multitude de look-and-feels

24. Prototype Objectif : obtenir une instance d’un objet à partir d’une autre instance Exemple : drag-and-drop de composants inconnus avec touche Ctrl enfoncée

25. Singleton Objectif : s’assurer qu’une seule instance d’un type spécifique existe dans le système et fournir l’accès à cet objet Exemple : un spooler d’impression

26. Adapter / Wrapper Objectif : obtenir un objet qui permet d’en utiliser un autre en conformité avec une certaine interface Exemple : mise en "conformité" de composants d’origines diverses

27. Proxy / Surrogate Objectif : obtenir un objet qui agit comme intermédiaire dans la communication avec un autre objet (un "passeur d’ordre") Exemples : un objet qui reporte les opérations coûteuses au moment où on utilise réellement les résultats de ces opérations (chargement d’une image à la fin d’un document, …) ; un objet qui transforme une collection en lecture-seule ; …

28. Composite Objectif : manipuler indifféremment des objets atomiques ou des agrégats d’objets Exemple : une application manipulant des formes graphiques et des compositions de ces formes

29. Decorator / Wrapper Objectif : ajouter à des instances spécifiques des comportements spécifiques Exemple : bordure d’un composant graphique

30. Facade Objectif : fournir une interface simplifiée et limitée à un système complexe Exemple : donner accès à des passes spécifiques d’un compilateur

31. Command Objectif : réifier une commande en un objet embarquant d’éventuels paramètres Exemple : uniformiser les différentes méthodes de commande d’un système et gérer l’undo et le redo

32. Command Pattern… • Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

33. Command Example

34. Command Example

35. Command Structure

36. Command Consequences • Command decouples the object that invokes the operation from the one that knows how to perform it. • Commands are first-class objects. They can be manipulated and extended like any other object. • It's easy to add new Commands, because you don't have to change existing classes.

37. Iterator Objectif : permettre d’itérer de manière générique sur les éléments d’une collection, quelle que soit la nature des éléments ou de la collection Exemple : trop naze, on le fait tous les jours

38. Observer / Listener Objectif : permettre à un objet d’informer d’autres objets qu’il ne connaît pas de l’évolution de son état interne Exemple : un bouton à la suite d’un click

39. Observer: Applicability • A change to one object requires changing an unknown set of others • Object should be able to notify others that may not be known at the beginning

40. Observer: Structure

41. Observer: Consequences • Abstract coupling between subject and observer • Support for broadcast communication • Hard to maintain

42. Observer View

43. Observer • One-to-many dependency between objects: change of one object will automatically notify observers

44. Strategy / Policy Objectif : utiliser de manière non spécifique une collection d’algorithme proches Exemple : algorithmes de tris de collections de données

45. State Objectif : un objet qui change de comportement en fonction de son état interne Exemple : une socket TCP (état non connectée, connectée, en attente de connection)

46. Visitor Objectif : découpler une structure des opérations sur cette structure Exemple : analyses/transformations d’arbres de syntaxe abstraite dans un compilateur

47. Combiner des Patterns

49. Et encore

50. Architectural Patterns… • From MUD to Structure… • Layers, Pipe and Filters, Blackboard • Distributed Systems… • Broker, Pipe and Filters, Microkernel • Interactive Systems… • MVC, PAC • Adaptable Systems… • Microkernel, Reflection…