La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 Motifs de conception ou “Design Patterns” Laurent

Présentations similaires


Présentation au sujet: "1 Motifs de conception ou “Design Patterns” Laurent"— Transcription de la présentation:

1 1 Motifs de conception ou “Design Patterns” Laurent

2 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 3 Contexte

4 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 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 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 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 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 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 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 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 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 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 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 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 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 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 18 Les Design Patterns Purpose CreationalStructuralBehavioral Scope Class Factory MethodAdapterInterpreter Template Method Object Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Proxy Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor

19 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 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 21 Structure

22 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 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 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 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 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 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 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 29 Decorator / Wrapper Objectif : ajouter à des instances spécifiques des comportements spécifiques Exemple : bordure d’un composant graphique

30 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 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 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 33 Command Example

34 34 Command Example

35 35 Command Structure

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

37 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 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 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 40 Observer: Structure

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

42 42 Observer View

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

44 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 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 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 47 Combiner des Patterns

48 48

49 49 Et encore

50 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…

51 51 Model-View-Contoler (MVC)  The model contains the core functionality and data?  Views display information to the user.  Controllers handle user input.  A change propagation mechanism ensure consistency between user interface and the model.

52 52 MVC

53 53 MVC Structure

54 54 MVC Structure

55 55 MVC Structure

56 56 MVC Known Uses  Smalltalk  SWING  Etc…

57 57 MVC benefits  Multiple views of the same model  Synchronized views: change propagation  Pluggable views and controllers  Exchangeability of ‘look and feel’  Framework potential

58 58 MVC Liabilities  Increased complexity  Potential for excessive number of updates  Intimate connection between view and controller  Close coupling of views and controllers to a model  Inefficiency of data access in view  Inevitability of change to view and controller when porting  Difficulty of using MVC with modern user-interface tools

59 59 Presentation-Abstraction-Control  PAC define a hierarchy of cooperating agents.  Each agent consists of three components: presentation, abstraction, control.  Separates human computer interaction from its functional core and its communication with other agents…

60 60 PAC Example

61 61 PAC Example

62 62 Broker  Used to structure distributed software systems with decoupled components that interact by remote service invocation.  A broker component is responsible for coordinating communication, such as forwarding request, as well as for transmitting result and exception.

63 63 And many others  Et beaucoup d’autres…

64 64 Summary (C. Alexander)  It is possible to make building by stringing together patterns, in a rather loose way. A building made like this, is an assembly of patterns. It is not dense. It is not profound. But it is also possible to put patterns together in such way that many patterns overlap in the same physical space: the building is very dense; it has many meanings captured in a small space; and through this density, it becomes profound.

65 65 Drawbacks of Patterns  Patterns do not lead to direct code reuse.  Individual Patterns are deceptively simple.  Composition of different patterns can be very complex.  Teams may suffer from pattern overload.  Patterns are validated by experience and discussion rather than by automated testing.  Integrating patterns into a software development process is a human­intensive activity.

66 66 Conclusion Des solutions-recettes adaptables pour des problèmes récurrents Des propositions de bases pour l’élaboration de solutions plus complexes Modèles parfois (souvent ?) triviaux

67 67 Exemples repris

68 68 Composite Pattern  Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

69 69 Composite Example

70 70 Composite Example

71 71 Composite Structure

72 72 Applying Composite on Command

73 73 Proxy Pattern  Provide a surrogate or placeholder for another object to control access to it.

74 74 Proxy Example

75 75 Proxy Structure

76 76 Proxy benefits 1.remote proxy can hide the fact that an object resides in a different address space. 2.A virtual proxy can perform optimizations such as creating an object on demand. 3.Both protection proxies and smart references allow additional housekeeping tasks when an object is accessed.

77 77 Adapter Pattern  Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

78 78 Adapter Example

79 79 Adapter Structure

80 80 Visitor Pattern  Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

81 81 Visitor example

82 82 Visitor example

83 83 Visitor applicability  many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations

84 84 Visitor Structure

85 85 Visitor Consequences 1.Visitor makes adding new operations easy 2.A visitor gathers related operations and separates unrelated ones 3.Adding new Concrete Element classes is hard 4.Visiting across class hierarchies 5.Accumulating state. 6.Breaking encapsulation


Télécharger ppt "1 Motifs de conception ou “Design Patterns” Laurent"

Présentations similaires


Annonces Google