Concepteur de logiciels (orienté objet, UML, modèles de conception)

orienté objet

• type
  • Une classe est une abstraction d'un objet, et un objet est une instance d'une classe
  • Classe d'entité
    • Classes de base (entités réelles dans le monde réel)
  • classe d'interface (classe limite)
    • Fournit aux utilisateurs un moyen d'interagir de manière coopérative avec le système (un moyen de contact pour les participants à l'intérieur et à l'extérieur du système)
  • classe de contrôle
    • Contrôler le flux des activités, agissant en tant que coordinateur (coordonner les interactions entre les objets de classe)
  • Classe général (véhicule) relation spéciale (navire, voiture, avion) ​​ps signifie qu'une grande plage comprend une petite plage
• objet
  • Les objets sont des entités de base, y compris les données (propriétés, états) et les opérations sur les données (services, comportements, méthodes)
  • Il se compose de trois parties : le nom de l'objet, les attributs et les méthodes.
  • Une construction pour communiquer entre des objets est appelée un message
• Surcharge de méthode : une classe peut avoir plusieurs méthodes portant le même nom mais des types de paramètres différents
  • Le nom de la méthode est le même mais le nombre de paramètres est différent
  • Même nom de méthode mais différents types de paramètres
  • Les noms de méthode avec le même ordre de type de paramètre sont différents
• Messages : demandes de service émises par des objets, assurant une communication mutuelle
• encapsulation
  • Un objet encapsule des attributs et des comportements dans leur ensemble, une technique de masquage d'informations. Une seule interface est exposée
• hériter
  • Un mécanisme de partage de données et de méthodes entre classes mères (superclasses, classes de base) et sous-classes (classes dérivées)
  • Une classe parent peut avoir plusieurs sous-classes, hériter d'une seule classe parent est un héritage unique et un héritage multiple est un héritage multiple.
  • L'enfant étend le parent et l'enfant peuvent remplacer la méthode du parent (override, replacement)
• polymorphisme
  • Différents objets reçoivent le même message et produisent des résultats complètement différents. Implémente la prise en charge de la réception de l'héritage
  • Nom de la classe parente nom de l'objet = nom de la nouvelle sous-classe () compiler (liaison statique) regarder à gauche, exécuter (liaison dynamique) regarder à droite
  • Polymorphisme générique
    • Polymorphisme paramétrique : le polymorphisme le plus répandu, le polymorphisme le plus pur
    • Polymorphisme d'inclusion : dans de nombreuses langues, un type est un sous-type d'un autre
  • polymorphisme spécifique
    • Polymorphisme de surcharge : le même nom signifie différentes choses dans différents contextes
    • polymorphisme obligatoire
• Principes de la conception orientée objet
  • Principe de responsabilité unique : en ce qui concerne une classe, il ne devrait y avoir qu'un seul principe qui la fait changer
  • Principe ouvert-fermé : ouvert pour extension, fermé pour modification
  • Principe de substitution de Liskov : les sous-classes doivent apparaître là où la classe de base apparaît
  • Principe d'inversion de dépendance : l'abstraction ne doit pas dépendre des détails, les détails doivent dépendre de l'abstraction, les modules de haut niveau ne doivent pas dépendre des modules de bas niveau (selon l'abstraction et non les détails (implémentation))
  • Principe de séparation d'interface : dépend de l'abstraction et non du concret
  • Principe commun de réutilisation : Réutilisez une classe dans un package, puis vous devez réutiliser toutes les classes du package
  • Principe de fermeture commun : si un changement en affecte un, il affectera toutes les classes du package, tandis que les autres packages n'auront aucun impact
• Analyse orientée objet OOA
  • Le but est d'acquérir une compréhension du problème d'application, et le but de la compréhension est de déterminer les exigences fonctionnelles et de performance du système
  • cinq étapes
    • Objet d'identification
      • En définissant (déterminant) le domaine du problème, traitez le "nom" naturel comme un objet
    • objet d'organisation
    • Décrire l'interaction entre objets (interaction entre objets)
    • Déterminer le fonctionnement de l'objet (opération basée sur l'objet)
    • Définir les informations internes de l'objet
• Conception orientée objet OOD
  • Transformez le modèle d'analyse créé par OOA en modèle de conception. L'objectif est de définir le schéma directeur de l'architecture du système (schéma modèle)
  • Comprendre la solution, mettre en œuvre les détails du système
  • Cinq activités correspondant à OOA : identifier les classes et les objets, définir les attributs, définir les services, identifier les relations et identifier les packages
• Programmation orientée objet POO
• Quatre niveaux de tests orientés objet : couche d'algorithme, couche de classe, couche de modèle, couche système
• développer
  • Une méthode statique d'une classe ne peut accéder qu'aux variables membres statiques de cette classe
  • Les membres de données statiques sont accessibles par toutes les méthodes de la classe
  • Les objets de cette classe partagent la valeur de ses membres statiques
  • Les objets ont des limites claires, un comportement bien défini et une extensibilité
  • Le modèle de classe de domaine contient des attributs, des opérations et des associations

Langage de modélisation unifié UML

• Blocs de construction UML
  • Une chose est une abstraction de la composante la plus représentative d'un modèle
    • Choses structurelles (nom statique) : classe, interface, collaboration, cas d'utilisation, classe active, composant, artefact, nœud
    • Choses comportementales (dynamique verbale) : interaction (message), machine à états (état), activité (action)
    • Regroupement d'éléments (section Organisation) : packages, Annotation d'éléments (section explication) : annotations
  • la relation maintient les choses ensemble
  • Le graphique rassemble des choses liées
  • Les interfaces UML peuvent être utilisées pour déclarer les services requis par les classes d'objets
• Quatre relations en UML
  • Dépendance : Un changement dans une chose indépendante A affectera la sémantique d'une autre chose dépendante B---->A La ligne pointillée représente
  • Association : une relation structurelle qui décrit un ensemble de chaînes, qui sont des connexions entre des objets
    • La relation est une ligne droite, sur laquelle vous pouvez marquer la multiplicité (répétabilité) et le rôle 0...1—0...* un-à-plusieurs
    • Plusieurs-à-plusieurs doivent créer une classe d'association (nouvelle classe)
    • Agrégation : associations de type spécial qui décrivent les relations structurelles entre les touts et les parties
      • Agrégation :—◇ Une partie de l'ensemble du cycle de vie est incohérente, le tout disparaît, la partie existe toujours et la partie peut exister sans le tout
      • Combinaison :—◇ les pièces (solides) ont le même cycle de vie global, l'ensemble disparaît, et la pièce disparaît également, et la pièce ne peut pas exister sans l'ensemble
  • Relation : l'objet de l'élément enfant (élément spécial) peut remplacer l'objet de l'élément parent (élément général) (la relation entre une classe et plusieurs classes), et l'enfant partage la structure et le comportement du parent. Le graphique est : une ligne pleine d'une flèche creuse (pan ), pointant vers l'élément parent
  • Réalisation : un classificateur spécifie une opportunité garantie d'être exécutée par un autre classificateur. Le graphique est : une ligne pointillée avec une flèche creuse, la classe pointe vers l'interface
• Diagramme UML

  • Diagramme de classes

    • Le diagramme le plus courant montrant un ensemble d'objets, d'interfaces, de collaborations et les relations entre eux
    • Modificateurs précédents : +public-private#protected~package's
    • Il est utilisé pour modéliser la vue de conception statique du système, la vue prend en charge les exigences fonctionnelles et les trois méthodes de modélisation utilisent des diagrammes de classes
      • Modélisation du vocabulaire d'un système, modélisation d'une collaboration simple, modélisation d'un schéma logique de base de données

  • graphique d'objets

    • Un ensemble d'objets et la relation entre eux à un certain moment, décrivant l'instantané statique de l'instance, comprenant généralement des objets et des graphiques en chaîne Nom de l'objet : attribut de nom de classe (a généralement une valeur) Aucune méthode

  • diagramme de cas d'utilisation

    • Lors de la modélisation de la vue de cas d'utilisation statique du système : modélisation du contexte du système, modélisation des exigences du système
    • Affiche un ensemble de cas d'utilisation, d'acteurs et de leurs relations (un diagramme représentant un cas d'utilisation est une ellipse)
      • Il existe une relation d'extension et d'inclusion entre les cas d'utilisation et les cas d'utilisation
        • Un cas d'utilisation de base (y compris le cas d'utilisation) - "include" -> B doit être exécuté avant que le cas d'utilisation inclus n'exécute A
        • Lorsqu'un cas d'utilisation est exécuté, certaines situations spéciales ou facultatives peuvent se produire, qui sont les cas d'utilisation étendus de ce cas d'utilisation
          • Cas d'utilisation étendu (cas particulier)----《étendre》—>cas d'utilisation de base
      • Généralisation entre cas d'utilisation et cas d'utilisation et acteurs.
        • Le graphique est : une ligne pleine avec une flèche creuse, la classe enfant pointe vers l'élément parent
      • Association entre acteurs et cas d'usage

  • diagramme interactif

    • Modélisez les aspects dynamiques du système, la transmission des messages entre eux. Les diagrammes d'interaction contiennent généralement des objets, des chaînes et des messages, et sont représentés sous forme de diagrammes de séquence et de diagrammes de communication
      • Diagramme de séquence (Séquence Diagram): Une représentation graphique d'une scène qui décrit les activités d'interaction entre les objets organisés dans l'ordre chronologique. L'objet interactif est placé en haut du graphique, du côté gauche où l'interaction est initiée et du côté droit de l'objet subordonné
        • Le diagramme de séquence a une ligne de vie d'objet, qui représente une ligne pointillée verticale, indiquant qu'un objet existe dans une période de temps. X signifie que la ligne de vie disparaît (se termine)
        • Le diagramme de séquence a un focus de contrôle, qui est représenté par un rectangle fin et haut, qui représente la période de temps pour qu'un objet exécute une action (la période de temps pour l'interaction de l'objet), qui peut être exécutée directement ou via un niveau inférieur. programme.
        • Message—> <------- renvoyer le message de manière synchrone besoin d'attendre le message de retour de manière asynchrone n'a pas besoin
      • Diagramme de communication (diagramme de collaboration) : met l'accent sur l'organisation structurelle des objets qui envoient et reçoivent des messages (montre le flux de messages et la séquence entre les objets)
        • Les graphiques de communication ont des chemins qui indiquent comment un objet est lié à un autre
        • Les diagrammes de communication ont des numéros de séquence, indiquant l'ordre chronologique des messages vagues

  • Diagramme d'état

    • Représente une machine d'état composée d'états, de transitions, d'événements et d'activités. Concentrez-vous sur une vue dynamique du système, en mettant l'accent sur la séquence des événements dans le comportement des objets. Modélisation d'objets réactifs (un objet)

      • Un état est un modèle observable de comportement du système qui peut à la fois changer d'état et effectuer des actions. Les états sont : état initial (point noir), état final (point noir plus un cercle), état intermédiaire.

      • Le diagramme d'état est un quadrilatère arrondi (puis divisé en supérieur, moyen et inférieur), la partie supérieure est le nom de l'état (doit avoir), la partie centrale est le nom et la valeur de la variable d'état (facultatif), et la partie inférieure la partie est la table d'activité (facultatif) La transition d'état entre les états, Le début est l'allumage ou le déclenchement, l'état initial ne peut avoir qu'un seul état final, multiple ou aucun

      • Diagramme d'activité = activité = actions multiples : nom de l'événement (ps qui sonne) / expression de l'action (ps qui répond au téléphone)

        • Trois noms d'événements standard
          

      • Conversion (migration) : la transition d'état entre les états est représentée par une ligne avec une flèche

        • Il y a deux états état d'origine ===== "état cible

      • Événement (déclenchera la conversion) : il s'agit de l'événement sur le logo de conversion, qui se produit à un certain moment, et qui résume les événements externes qui font passer l'action du système d'un état à un autre.

        • Expression : description de l'événement [condition du gardien]/expression de l'action
          • Utilisez la description de l'événement et la condition de garde (booléenne) en même temps, si et seulement si l'événement se produit et que la condition est vraie, la transition d'état se produira.
          • S'il n'y a qu'une condition de surveillance (booléenne) et aucune description d'événement, la condition est vraie et une expression d'action peut se produire lors de la transition d'état (si aucun événement n'est marqué, il basculera automatiquement après la fin de l'activité interne)

      • Les activités (actions) peuvent être exécutées dans un état ou lors de transitions d'état (transitions)

      • Les états composites (super-états) contiennent des états imbriqués (sous-états)

  • Diagramme d'activité

    • Un type spécial de diagramme d'état qui passe d'une activité à une autre. (La différence avec l'état est qu'il n'y a pas de temps sur la flèche en trait plein et qu'il n'y a qu'une expression de gardien [])
    • Modélisation du workflow, modélisation des opérations, deux manières d'utiliser les diagrammes d'activité

  • Schéma d'architecture (Schéma de composants)

    • L'organisation et les dépendances entre un ensemble de composants. Vue d'implémentation statique, liée aux diagrammes de classes, où les composants sont mappés à une ou plusieurs classes, interfaces et collaborations.
      

  • schéma de déploiement

    • Une méthode pour modéliser les aspects physiques des diagrammes orientés objet, (stéréo) statiques par rapport aux composants
    • Montre la relation entre le logiciel et le matériel du système, utilisé dans la phase de mise en œuvre
    • Les dépendances entre les composants de déploiement sont similaires aux dépendances de package

  • Résumer
    

Modèles de conception

• Éléments des modèles de conception

  • Fournir des solutions aux problèmes connexes, ce qui permet aux gens de réutiliser plus facilement et plus facilement les conceptions et les architectures réussies
  • Quatre éléments : nom du modèle, problème, solution, effet
  • Chaque modèle de conception se concentre sur un problème ou un point de conception spécifique orienté objet
    

• Modèles de conception de création

  • Différents types d'informations sont encapsulés, et ce que le système entier connaît de ces objets est l'interface définie par le verrou abstrait
  • Modèle de méthode d'usine (classe)
    • L'intention est de définir une interface pour créer des objets, laissant les sous-classes décider quelle classe instancier, et des méthodes d'usine pour différer l'instanciation d'une classe à ses sous-classes
    • Applicable lorsqu'une classe ne connaît pas la classe de l'objet qu'elle crée, et lorsqu'une classe veut que ses sous-classes spécifient l'objet qu'elle crée
  • modèle d'usine abstraite
    • L'intention est de fournir une interface pour créer une série d'objets liés ou interdépendants sans spécifier sa classe concrète
    • Lorsqu'un système doit être indépendant de la création, de la composition et de la présentation de ses produits
    • Lorsqu'un système doit être configuré par l'une de plusieurs familles de produits
    • Lorsque la conception d'une série d'objets produits connexes doit être mise en valeur pour une utilisation conjointe
    • Lorsque vous fournissez une bibliothèque de classes de produits et que vous souhaitez uniquement afficher leurs interfaces, mais pas leurs implémentations
    • ps : définir des hiérarchies de classes parallèles pour différentes plates-formes pour les composants d'interface utilisateur graphique, adaptés aux usines abstraites
  • modèle de générateur
    • Séparer les composants d'un objet complexe de sa représentation afin qu'un même processus de construction puisse créer différentes représentations
    • Applicable lorsque l'algorithme de création d'un objet complexe doit être indépendant des éléments constitutifs de l'objet et de la façon dont ils sont assemblés
    • Lorsque la procédure de construction doit permettre différentes représentations des objets en cours de construction
  • modèle de prototype
    • L'intention est que les instances de prototype spécifient le type d'objets à créer, et de nouveaux objets sont créés en dupliquant ces prototypes
    • Applicable lorsqu'un système doit être créé, construit et représenté indépendamment de ses produits
    • Lorsque la classe à instancier est spécifiée à l'exécution, par exemple, par chargement dynamique
    • Pour éviter de créer une hiérarchie de classe d'usine parallèle à la hiérarchie de classe de produit lorsque
    • Lorsqu'une instance d'une classe ne peut avoir qu'une seule combinaison d'états parmi plusieurs, il peut être plus pratique de créer un nombre correspondant de prototypes et de les cloner que d'instancier manuellement la classe à chaque fois avec l'état approprié.
  • motif singleton
    • L'intention est de s'assurer qu'une classe n'a qu'une seule instance et de lui fournir un point d'accès global
    • Applicable lorsqu'une classe ne peut avoir qu'une seule instance et que les clients peuvent y accéder à partir d'un point d'accès bien connu
    • Lorsque la seule instance doit être sous-classable et que les clients peuvent utiliser une instance étendue sans modification du code

• Modèles de création structurelle

  • Comment combiner des classes et des objets pour obtenir des structures plus grandes, en utilisant le mécanisme d'héritage pour combiner des interfaces ou des implémentations

  • modèle d'adaptateur (classe)

    • Convertit l'interface d'une classe en une autre interface souhaitée par le client. Le mode adaptateur permet aux classes qui ne peuvent pas fonctionner ensemble en raison d'interfaces incompatibles de fonctionner ensemble.
    • Vous souhaitez utiliser une classe existante dont l'interface ne répond pas aux exigences
    • Vous voulez créer une classe réutilisable qui fonctionne avec d'autres classes non liées ou imprévues (comprendre)
    • Vous voulez utiliser une sous-classe existante, mais il est impossible de sous-classer chacune pour correspondre à son interface, l'adaptateur d'objet peut adapter son interface de superclasse (uniquement pour les objets)

  • mode pont

    • Séparer la partie abstraite de son implémentation afin qu'elles puissent toutes les deux varier indépendamment
      

  • mode combiné

    • Combinant des objets dans une structure arborescente pour représenter une hiérarchie "partie-tout", la combinaison permet aux utilisateurs d'utiliser les objets combinés d'un seul objet avec cohérence
    • Convient pour vouloir représenter des hiérarchies partie-tout d'objets
    • On espère que l'utilisateur ignorera la différence entre l'objet composite et l'objet unique, et l'utilisateur utilisera tous les objets de la structure composite de manière uniforme

  • motif décorateur

    • L'intention est d'ajouter dynamiquement des responsabilités supplémentaires à un objet
    • Ajoutez dynamiquement et de manière transparente des responsabilités à des objets individuels sans affecter les autres objets
    • Gérer les responsabilités qui peuvent être révoquées

  • mode d'apparence

    • L'intention est de fournir une interface cohérente à un ensemble d'interfaces d'un sous-système
    • Lorsque vous souhaitez fournir une interface simple à un sous-système complexe
    • Il existe une grande dépendance entre le programme client et la partie implémentation de la classe abstraite
    • Lorsque vous devez créer un sous-système hiérarchique, utilisez-le pour définir le point d'entrée de chaque couche du sous-système.

  • Mode poids mouche

    • L'intention est de prendre en charge efficacement un grand nombre d'objets à granularité fine à l'aide de techniques de partage
    • Une application utilise un grand nombre d'objets
    • Entièrement dû au grand nombre d'objets, entraînant une surcharge de stockage importante
    • La plupart des états d'un objet peuvent devenir des états externes
    • De nombreux groupes d'objets peuvent être remplacés par relativement peu d'objets partagés si les transitions externes des objets sont supprimées

  • Mode mandataire

    • L'intention est de fournir un proxy pour d'autres objets afin de contrôler l'accès à cet objet
      

• Modèles de conception comportementaux

  • Concevoir des algorithmes et l'attribution des responsabilités entre les objets, décrire les schémas des objets et des classes, et les schémas de communication entre eux
  • mode interprète
    • L'intention est, étant donné une langue, de définir une représentation de sa grammaire et de définir un interpréteur qui utilise cette représentation pour interpréter des phrases dans la langue
    • Lorsqu'un langage doit être interprété et exécuté, et que les phrases du langage peuvent être représentées sous la forme d'un arbre de syntaxe abstraite
    • La grammaire est simple et l'efficacité n'est pas un problème critique
  • modèle méthode modèle
    • L'intention est de définir le squelette d'un algorithme dans une opération, tout en reportant certaines étapes aux sous-classes. Les modèles permettent aux sous-classes de redéfinir certaines étapes d'un algorithme sans changer la structure de l'algorithme
    • Implémenter les parties constantes d'un algorithme à la fois, laissant le comportement variable aux sous-classes
    • Les comportements communs aux sous-classes doivent être extraits et centralisés dans une classe parente commune pour éviter la duplication de code
    • contrôler l'extension de la sous-classe
  • modèle de chaîne de responsabilité
    • Les intentions évitent le couplage entre l'expéditeur et le destinataire d'une demande en donnant à plusieurs objets une chance de gérer la demande. Liez ces objets dans une chaîne et transmettez la demande le long de la chaîne jusqu'à ce qu'un objet la gère.
    • Il existe plusieurs objets qui peuvent gérer une demande, et quel objet gère la demande est automatiquement déterminé au moment de l'exécution
    • Souhaitez soumettre une demande à l'un des multiples objets sans spécifier explicitement le destinataire
    • L'ensemble des objets pouvant gérer une requête doit être spécifié dynamiquement
  • mode de commande
    • L'intention est d'encapsuler une requête dans un objet, afin que différentes requêtes puissent être utilisées pour paramétrer les clients, aimer les requêtes ou enregistrer les journaux de requêtes, et prendre en charge les opérations annulables.
    • Résumé de l'action à effectuer et paramétrage d'un objet
    • Spécifiez, mettez en file d'attente et exécutez les demandes à différents moments
    • Prise en charge de l'annulation de l'opération Prise en charge du journal des modifications
    • Construire un système avec des opérations de haut niveau basées sur des opérations primitives
  • modèle d'itérateur
    • L'intention est de fournir un moyen d'accéder séquentiellement aux éléments d'un objet agrégé sans exposer la représentation interne de l'objet
    • Accéder au contenu d'un objet agrégé sans exposer sa représentation interne
    • Prend en charge plusieurs traversées d'objets agrégés
    • Fournir une interface commune pour traverser différentes structures d'agrégation
  • modèle de médiateur
    • L'intention est d'utiliser un objet intermédiaire pour encapsuler une série d'interactions d'objets
    • Un ensemble d'objets communiquent de manière bien définie mais complexe, ce qui entraîne des interdépendances non structurées et difficiles à comprendre
    • Un objet fait-il référence à de nombreux autres objets et communique-t-il directement avec ces objets, ce qui rend difficile la réutilisation de l'objet
    • Vous souhaitez personnaliser un comportement réparti sur plusieurs classes sans générer trop de sous-classes
  • mode mémo
    • L'intention est de capturer l'état interne d'un objet sans rompre l'encapsulation, et d'enregistrer cet état en dehors de l'objet, afin que l'objet puisse être restauré ultérieurement à l'état enregistré d'origine.
    • L'état d'un objet à un certain moment doit être enregistré afin qu'il puisse être restauré à un état antérieur si nécessaire ultérieurement
    • Si l'on utilise une interface pour permettre à d'autres objets d'obtenir ces états directement, cela exposera les détails d'implémentation de l'objet et cassera l'encapsulation de l'objet
  • Modèle d'observateur
    • L'intention est de définir une relation de dépendance un-à-plusieurs entre les objets. Lorsque l'état d'un objet change, tous les objets qui en dépendent sont notifiés et automatiquement mis à jour.
    • Lorsqu'un modèle abstrait a deux aspects, dont l'un dépend de l'autre, encapsulez les deux dans des objets séparés afin qu'ils puissent être modifiés et réutilisés indépendamment
    • Lorsqu'une modification d'un objet nécessite des modifications d'autres objets en même temps et que l'on ne sait pas exactement combien d'objets doivent être modifiés
    • Lorsqu'un objet doit notifier d'autres objets, mais qu'il ne peut pas supposer qui sont les autres objets, ni ne veut que ces objets soient étroitement couplés
  • mode d'état
    • L'intention est de permettre à un objet de modifier son comportement lorsque son état interne change. L'objet semble avoir modifié sa classe
    • Le comportement d'un objet est déterminé par son état, et il doit changer son comportement au moment de l'exécution en fonction de l'état
    • Il existe d'énormes instructions conditionnelles multi-branches dans une opération, et ces branches dépendent de l'état de l'objet. Cet état est souvent représenté par une ou plusieurs constantes d'énumération
  • modèle de stratégie
    • L'intention est de définir une série d'algorithmes, de les encapsuler un par un et de les rendre interchangeables. Ce mode permet aux algorithmes de varier indépendamment des clients qui les utilisent
    • De nombreuses classes liées se comportent simplement différemment
    • Différentes variantes d'un algorithme doivent être utilisées
    • Les algorithmes utilisent des données que les clients ne devraient pas connaître
    • Une classe définit une variété de comportements, et ce comportement apparaît sous la forme de plusieurs instructions conditionnelles dans le fonctionnement de cette classe, et les branches conditionnelles pertinentes sont déplacées dans leurs classes de stratégie respectives pour remplacer ces instructions conditionnelles. (Les membres juniors clients, les membres intermédiaires et les membres seniors bénéficient de réductions différentes)
  • modèle de visiteur
    • Une intention représente une opération à effectuer sur des éléments d'une structure d'objet. Il définit de nouvelles opérations sur les éléments sans changer leur classe
    • Une structure d'objet contient de nombreux objets de classe avec différentes interfaces, et l'utilisateur souhaite effectuer certaines opérations sur ces objets qui dépendent de leurs classes spécifiques
    • La classe qui définit la structure de l'objet change rarement, mais a souvent besoin de définir de nouvelles opérations sur cette structure
    • Besoin d'effectuer de nombreuses opérations différentes et sans rapport sur des objets dans une structure d'objet