Aide Mémoire Design Pattern [PDF]

Zitiervorschau

factory Définition Le design pattern factory fournie un mécanisme pour utiliser une instance comme une usine à objet. Le factory peut retourner une instance d’un objet parmi plusieurs types (ordonnées dans une relation d’héritage), en fonction des données qu’on lui fournit

Quand l’utiliser  Quand une classe ne peut pas anticiper quel type d’objet elle doit créer  Quand on veut rendre local la connaissance de quelle classe doit être créée  Quand on a des classes qui héritent d’une même classe mère ou même des classes indépendantes qui partagent la même interface. Ainsi les méthodes dans ces classes sont les mêmes et peuvent être interchangeables  Quand on veut isoler le client du type actuel de classes qui est en train d’etre instancié Bénéfices Le client n’a pas besoin de connaitre chaque classe fille des objets qu’il doit créer, il a besoin juste d’une référence à la classe abstraite ou interface et l’objet factory Le factory encapsule la création d’objets, ceci peut être utile lorsque le processus de création est très complexe. Conséquences/retombées Il n’y pas d’autre moyen de changer l’implémentation d’une classe sans une recompilation totale.

Abstract Factory Définition Une factory abstraite est un pattern créationnel qui est relié au pattern factory, en lui rajoutant une nouvelle couche d’abstraction. Ce qui veut dire que ce pattern encapsule un groupe de classes factory individuelle (à l’opposé du factory qui a des méthodes abstraites dérivées dans les classes filles) qui partagent des interfaces communes. Le client utilise l’abstract factory qui fournit une interface pour créer des familles d’objets liés ou dépendants sans spécifier leurs classes concrètes. Ce pattern sépare les détails d’implémentation d’un jeu d’objets de son utilisation en général.

Quand l’utiliser Ce pattern peut être utilisé quand on doit créer un jeu d’objets qui partagent le même thème, et ou le client a juste besoin de savoir comment gérer l’équivalent abstrait de cet objet, comme lorsque l’implémentation n’est pas importante pour le client, ou le cas où il a juste besoin de traiter certains attributs en se souciant de leur signification et non de leur contenu. L’abstract factory est surtout utilisée lorsqu’il y a un besoin d’utiliser différents types d’objets et ou les objets peuvent être ajoutés ou changés durant le cycle de vie d’exécution d’une application Bénéfices L’utilisation de ce pattern rend les classes concrètes interchangeables sans changer le code qui les utilise, même durant l’exécution de l’application les objets peuvent être intervertis Conséquences/retombées Comme pour les design patterns similaires l’inconvénient majeur est l’introduction d’une nouvelle complexité parfois non nécessaire, et le travail supplémentaire que ça implique pour arriver à créer tout simplement une instance.

Builder Définition Le pattern builder peut être utilisé pour faciliter la construction d'objets complexes depuis des objets simples. Il sépare la construction d'objets complexes de leurs représentations ainsi le même processus de construction peut être utilisé pour construire des objets similaires. Les patterns reliés sont Abstract factory et composite

Quand l'utiliser  Quand l'algorithme de création d'objets doit être indépendant des fragments constituants l'objet et comment ils doivent être assemblés  Quand le processus de construction doit permettre plusieurs représentations de l’objet construit  Quand on veut empêcher les clients de connaitre le processus de création et/ou le résultat produit Bénéfices  Le produit construit est indépendant des détails de sa construction  Le code de construction est isolé du code de la représentation et chacun est facilement remplaçable/modifiable sans toucher à l’autre  Permet d’avoir un contrôle sur le processus de construction  Permet de réutiliser et/ou de changer le processus et/ou le produit indépendamment. Conséquences/retombées  Nécessite une grande flexibilité pour la création d’objets complexes varies.  Nécessite la création d’objets complexes et d’agrégats d’objets

Prototype Définition Le pattern prototype est d’une façon basique la création de nouvelles instances par le clonage d’instances existantes, en créant un prototype les nouveaux objets sont tout simplement crées par copie du prototype

Quand l’utiliser  Quand un système nécessite une indépendance vis-à-vis de la création de nouveaux objets, composés et représentés.  Quand on veut rajouter et enlever des objets d’une façon dynamique au runtime  Lorsque on peut spécifier de nouveaux objets en changeant simplement les objets existants  Quand on configure une application avec des classes d’une façon dynamique  Quand on veut réduire le nombre de classes dans un système au minimum  Lorsque la gestion d’états d’une population d’instance est difficile, couteux, ou exclusif Bénéfices  Augmente les performances lors de la création d’objets volumineux, de classes chargées dynamiquement  Réduit les héritages, les classes filles Conséquences/retombées Chaque classe héritant ou dérivant du prototype doit implémenter la méthode Clone. Ceci peut être difficile avec des classes existantes, avec des objets internes aux références circulaires (un objet en appelant un autre … etc appelant un autre appelant le tout premier objet), ou qui ne supportent pas la copie.

Singleton Définition Le pattern singleton permet la possibilité de contrôler un nombre d’instance (le plus souvent une seule) qui peuvent être fabriquées, on aura en même temps un point d’accès globale à ces instances.

Quand l'utiliser Quand une seule instance ou un nombre spécifique d’instances d’une classe sont autorisés, les objets façades sont souvent des singletons parce qu’une seule façade est requise. Bénéfices  Un accès contrôlé à une instance unique  Réduit l’espace de nom (l’espace commun des variables globales)  Permet le raffinement des opérations et des représentations Conséquences/retombées Le pattern singleton est considéré par certains comme un anti-pattern (une mauvaise habitude de conception), à cause d’une surutilisation, d’une limitation non nécessaire pour l’utilisation d’une seule instance d’une classe alors qu’on n’en a pas besoin.

Adapter pattern Définition Le design pattern adapter est utilisé pour transformé une interface d’une classe en une autre interface. Ceci implique qu’on peut faire que des classes peuvent travailler ensemble alors que c’était impossible avant à cause d’une incompatibilité de leurs interfaces. Une classe adaptateur utilise des héritage multiple (en étendant une classe et/ou en implémentant une ou plusieurs classes) pour adapter une interface à une autre. Un objet adaptor est relié à l’agrégation d’objets.

Quand l’utiliser  Quand on veut utiliser une classe existante et que son interface ne convient pas à nos besoins  Quand on veut créer une classe réutilisable qui coopère avec des classes non liées ou non visibles, ou des classes qui ont des classes incompatibles.  Lorsqu’on veut augmenter la transparence d’une classe  Lorsqu’on veut faire un kit pluggable Bénéfices  Une classe hautement réutilisable  Permet de rajouter uniquement un seul objet Conséquences/retombées Lorsqu’on utilise java, la cible doit être une interface

Bridge Définition Découple une classe abstraite ou une interface de son implémentation, ainsi les deux peuvent évoluer indépendamment. Le design pattern Bridge trace une ligne de démarcation entre une classe abstraite et son implémentation

Quand l'utiliser    

Lorsqu’on veut séparer une structure abstraite et son implémentation concrète Lorsqu’on veut partager une implémentation entre plusieurs objets Lorsqu’on veut réutiliser les ressources existantes en un mode « facile à étendre » (offrir un produit qui est facilement configurable au niveau des classes métier par exemple) Lorsqu’on veut cacher les détails de l’implémentation aux clients. Un changeme nt d’implémentation ne devrait pas avoir d’impact sur les clients.

Bénéfices  

L’implémentation peut être sélectionnée ou changée lors de l’exécution dans le runtime. L’abstraction et l’implémentation peuvent être étendues ou composées avec d’autres classes indépendamment l’une de l’autre

Conséquences/retombées Une double redirection. Par exemple les méthodes implémentées par une classes filles d’une API de dessin graphique. Les classes contrôleurs doivent déléguer les messages à une classe fille d’une API de dessin, qui implémente la méthode appropriée. Ceci peut avoir des conséquences sur les performances, car la pile d’appel des méthodes s’en trouve allongée.

Composite

Définition Le pattern composite peut nous aider à créer des structures en forme d’arbre sans nous obliger à différencier entre les branches et les feuilles au regard de l’usage, comme c’est le cas de linux ou tout est fichier, même les dossiers, qui sont des conteneurs d’autres fichiers. Ce pattern nous assure que le client va traiter les objets individuels et la composition des objets d’une façon uniforme.

Quand l'utiliser  Lorsqu’on veut représenter une structure en arbre  Lorsqu’on veut rendre le code indifférent à la différence entre une feuille et une branche (une composition de feuilles)  Lorsque la structure peut avoir un degré de complexité inconnu au départ et/ou est dynamique Bénéfices  Définie une hiérarchie de classes consistante en des objets primitifs et des objets composites  Facilite l’ajout de nouveaux types de composants. Conséquences/retombées Le pattern composite nous assure une facilité à ajouter de nouveaux genres de composants à des collections du moment qu’elles supportent une interface de programmation similaire. D’un autre coté ceci à l’inconvénient de rendre le système trop généraliste. Il se peut qu’il soit diffic ile de rendre le système restreint à certaines classes lorsque celui-ci doit l’être.

Decorator Définition Le pattern decorator peut nous laisser attacher des responsabilités additionnelles à une classe et modifier ses fonctionnalités dynamiquement. Le decorator fournit une alternative à l’hérita ge pour étendre des fonctionnalités, en utilisant la composition à la place de l’héritage.

Quand l'utiliser  Quand on veut ajouter des responsabilités à des objets individ uels dynamiquement et d’une façon transparente, sans affecter l’objet original ou d’autres objets.  Lorsqu’on veut ajouter des responsabilités à un objet, responsabilités qui vont changer dans le futur  Lorsque l’extension par l’héritage classique est impraticable. Bénéfices  Plus de flexibilité qu’un héritage classique  Simplifie le développement, parce qu’on écrit une série de classes spécifiques aux fonctionnalité au lieu de rajouter les fonctionnalités à chaque classe, avec les différentes combinaisons possibles de fonctionnalités  Augmente la robustesse des objets, leurs capacités à être étendues parce qu’on code en rajoutant de nouvelles classes et non en modifiant les existantes Conséquences/retombées Ce qu’on doit avoir en tête lorsqu’on implémente le pattern decorator est qu’on doit simplifier l’interface le plus possible. Rendre l’interface complexe rend l’application des decorators fastidieuse. Un autre inconvénient est lorsqu’on utilise une série de décorateur, ceci peut avoir des impacts sur les performances. Le tout dernier inconvénient est que le type de l’objet décoré est uniquement le dernier décorateur qu’on lui a appliqué, on n’a de visibilité ni sur la série de décorateurs, ni sur l’objet originel.

FACADE Définition Ce design pattern fourni une interface unifiée a un ensemble d’interfaces dans un sous-système. Il définit une interface de haut niveau qui permet une utilisation plus aisée du sous système Une façade est un objet qui fournit une interface simplifiée à de grandes parties de code, comme les classes bibliothèques. Quand l'utiliser Le design pattern façade peut être utilisé pour alléger l’utilisation d’une bibliothèque logicie lle, en offrant des méthodes lisibles pour les taches courantes. Pour la même raison, il rend le code beaucoup plus lisible. Le même pattern peut être utilisé pour réduire la dépendance au code externe lorsqu’on travaille à l’intérieur d’une bibliothèque pour construire de nouvelles méthodes ou pour encapsuler les objets dont on a besoin dans des méthodes plus simples à invoquer, et ce dans la plupart des langages qui offrent cette possibilité là, ce qui nous permet plus de flexibilité lorsqu’on développe un système. Un dernier cas de figure consiste à encapsuler une API très mal adaptée au besoin ou très pauvre, ou très mal conçue pour la rendre plus robuste ou plus apte à nos besoins. Bénéfices Le bénéfice principal de ce design pattern est de pouvoir combiner des appels de méthodes complexes et des blocs de code en une seule méthode qui va effectuer une tâche complexe et récurrente. En plus de rendre le code plus facile à utiliser et à comprendre, il réduit les dépendances entre les différentes librairies ou packages, rendant ainsi les développeurs plus aptes à envisager des alternatives avant d’écrire un nouveau code qui va exposer le travail interne qui se fait au niveau du package. Aussi depuis lors qu’une façade rend le couplage entre le code client et les autres paquages ou bibliothèques faible, elle nous permet de changer les composants internes que le client n’appelle pas directement. Conséquences/retombées La conséquence logique quand on masque ce qui se passe en dessous d’une façade est qu’on a moins de contrôle sur ce qui s’y passe réellement, Aussi lorsqu’une classe requiert une variatio n minime d’une implémentation d’une méthode d’une façade, on peut se retrouver en face d’un problème assez complexe.

Flyweight Définition Le flyweight (littéralement poids plume) fournie un mécanisme avec lequel on évite la création d’un nombre élevé d’objets « couteux », à la place on réutilise les instances déjà existantes pour représenter des nouvelles.

Quand l'utiliser  Lorsqu’il y a un grand nombre d’objets qui peuvent ne pas tenir tous en mémoire  Lorsque la majeur partie d’un objet peut être stockée sur un disque ou calculée par le runtime  Lorsqu’il y a des groupes d’objets qui peuvent partager un état  Lorsque le statut de l’objet peut être factorisé dans un nombre relativement réduit d’objets avec un state partagé Bénéfices Réduit le nombre d’objets crées, réduit l’empreinte sur la mémoire et accroit les performances Conséquences/retombées Le design des objets très proches aux couches les plus profondes du système en terme de granularité assure une flexibilité optimale, mais peut très facilement devenir couteux en terme de performance et d’utilisation mémoire contrairement au but escompté.

PROXY Définition Le proxy est un pattern structurel qui assure un contrôle d’un autre objet, au niveau de l’utilisation comme au niveau du contrôle d’accès. Quand l'utiliser  Lorsque la création d’un objet est relativement couteuse, une bonne idée est de le remplacer avec un proxy qui va rendre l’institution aussi minimale que possible.  Ce pattern permet des vérifications (par exemple sur les noms d’utilisateurs, ou sur les autorités) avant de solliciter l’objet contrôlée pour vérification  Peut être utilisé pour représenter localement un objet distant. Bénéfices Donne la possibilité de contrôler l’accès à un objet, soit pour des raisons de cout, soit pour des raisons de sécurité. Conséquences/retombées Rajoute un nouveau niveau d’abstraction pour un objet donné, si certains objets accèdent à l’objet cible directement d’autre via le proxy, il y a des chances pour qu’ils aient différents comportements ou représentations d’un même objet, ceci peut être voulu par le concepteur, mais parfois ceci peut poser problème au développeur.

Chain-of-responsibility Définition Ce design pattern permet qu’une requête soit interceptée et traitée par plusieurs objets sans que l’un d’eux ait connaissance des autres. On évite ainsi le couplage entre un émetteur et les récepteurs possibles. On place tous les récepteurs dans une chaine qui permet aux objets récepteurs de passer la requête au récepteur suivant jusqu’à ce que l’un des récepteurs traite la requête ou que la fin de la chaine soit atteinte.

Quand l’utiliser  Quand on veut que plusieurs objets (plus qu’un) interceptent une requête, mais qu’on ignore lequel exactement va le faire.  Quand on veut envoyer une requête à un de plusieurs objets, sans connaitre lequel exactement.  Quand l’ensemble des objets qui doivent traiter une requête doit être spécifié dynamiquement ou qu’il va changer durant l’exécution de l’applicatio n.

Bénéfices  Il réduit le couplage  Il augmente la flexibilité lorsqu’on traite une requête (handling) Conséquences/retombées La réception n’est pas garantie vu qu’une requête n’a pas un récepteur explicite, il n’y a pas de garantie qu’elle soit traitée sauf si la chaine est configurée correctement.

command Définition Le pattern command est utilisé pour créer des objets qui représentent des actions et des évènements dans une application. Un Objet de type command encapsule une action ou un évènement et contient toutes les informations nécessaires pour comprendre exactement ce qui s’est passé. En passant l’objet command comme paramètre permet, à n’importe quel endroit, d’extraire les informations à propos des actions et des évènements arrivés.

Quand l’utiliser  Lorsqu’on veut une action qui peut être représentée par plusieurs façons, comme un menu dropdown, un boutton ou un menu popup  Lorsqu’on veut créer une fonctionnalité undo/redo Bénéfices  Un objet de type command est un lieu de stockage possible des paramètres des procédures. Il peut être utilisé lorsqu’on rassemble les paramètres pour un appel d’une fonction et permet de mettre de côté le command pour une utilisation ultérieure.  Une classe est endroit approprié pour collecter du code et des données relatives à certaines actions ou évènements.  Il permet à une réaction au command d’être exécutée après un certain temps qu’il soit arrivé  Les objets command permet d’avoir des structures de données contenant des commandes multiples  Les objets de type command permettent d’avoir des opérations réversibles (undo), par le biais d’objets command stockés (dans une liste chainée dynamique par exemple) Conséquences/retombées Le plus gros inconvénient de ce pattern est la prolifération de petites classes qui surchargent le programme. Ceci dit, même si on se retrouve dans le cas où on a des évènements de clicks séparés, on appelle habituellement des méthodes privées assez courtes pour effectuer les fonctions actuelles, ce qui revient au même. Ces petites méthodes ont les mêmes inconvénie nts que nos classes. Bâtir une classe Command ou écrire plus de méthodes ont le même degré de complexité, la plus grande différence est que lorsqu’on utilise le pattern Command produit de petites classes et non de grandes classes avec des petites méthodes, ce qui rend le code beaucoup plus lisible.

Iterator Définition Le design pattern iterator fournit un moyen d’accéder aux éléments d’un agrégat d’objet (une collection), d’une façon séquentielle, sans exposer les mécanismes internes de stockage et de représentation. .

Quand l'utiliser A utiliser lorsqu’on souhaite un accès séquentiel a un agrégat d’objets. Les java collections comme ArrayList et HashMap ont implémenté ce design pattern. Bénéfices  Le même iterator peut être utilisé pour différents agrégats  Permet de parcourir l’agrégat en plusieurs sens, en fonction des besoins  Encapsule la structure interne du comment l’itération se produit  Ne bloque pas les classes pour des opérations données lorsqu’on veut parcourir l’agrégat en même temps qu’on effectue une opération sur un élément de l’agrégat par exemple. Conséquences/retombées Si l’iterator n’est pas robuste, il ne peut pas être considéré comme fiable lorsqu’on travaille avec le multi-threads (problemes de synchronisation). Pour pallier à ce problème l’iterator doit permettre l’insertion et la suppression par des méthodes synchronisées, si cela est impossible à réaliser il faut travailler avec un memento qui doit sauvegarder l’état de l’iterator

Mediator Définition Avec le Pattern mediator, les communications entre objets est encapsulée dans un objet appelé mediator. Les objets ne communiquent plus chacun avec l’autre, mais communiquent avec (et via) uniquement le mediator. Le résultat est une implémentation plus cohérente de la logique et un couplage plus lâche entre les objets.

Quand l’utiliser Le pattern Mediator peut être utilisé lorsque des objets d’un même ensemble communiquent de manière bien définie mais complexe, les interdépendances qui en résultent seront non structurées et difficiles à saisir. S'il est difficile de réutiliser un objet car il se réfère à de nombreux objets et/ou communique avec eux, ce modèle est une bonne solution. Les identités des objets communicants seront protégées lorsqu’on utilise le pattern Mediator qui est un bon moyen lorsque la sécurité est importante. En plus si on souhaite personnaliser un comportement qui se répartie entre plusieurs classes sans avoir recours à plusieurs sous-classes ce pattern peut être utilisé. Ce pattern est utilisé dans plusieurs systèmes qui travaillent sur les protocole d’envoi et de réception, comme les listes de diffusions, ou les serveurs de tchat. Un autre domaine d’application est les interfaces utilisateurs (GUI) où le Mediator peut encapsuler un comportement collectif à contrôler et coordonner les interactions d’un groupe de widgets d’une GUI. Le Mediator sert d’intermédiaire qui permet aux objets du groupe de coopérer/communiquer sans se référer l’un à l’autre explicitement. Tous les objets ne connaissent que le mediator et se réfèrent à lui, ce qui limite le nombre d’interconnexions. Bénéfices Le mediator a cinq avantages et retombées principales :  Limiter les héritages, du moment que le mediator s’occupe du comportement qui normalement devrait être distribué sur les objets. Changer ce comportement ne requiert plus de faire une classe fille pour chaque objet, mais de créer une classe fille pour le mediator.



 



Les classes autres que le mediator sont découplées les unes des autres, ce qui nous permet de les réutiliser à souhait, si on désire changer le comportement en gardant la même interface par exemple il suffit d’adresser le composant graphique à un autre mediator. Mediator simplifie le protocole de communication entre objets. Du moment qu’il remplace le protocole d’interaction many-to-many par un protocole one-to-many qui est un protocole plus facile à comprendre, maintenir et développer. Le mediator rend la coopération entre objets abstraite. Le mediator nous permet de nous concentrer sur comment les objets interagissent séparément de leur propre comportement, ce qui rend le « comment les objets interagissent dans le système » plus facile à comprendre. Un contrôle centralisé est réalisé en déplaçant la complexité des interactions et en la concentrant dans le mediator. Le mediator encapsule les protocoles et peut devenir beaucoup plus complexe que les autres objets du groupe. Ceci peut rendre le mediator très complexe et difficile à maintenir.

Conséquences/retombées Au-delà des bénéfices et des conséquences citées dessus. Une retombée important est que le mediator peut avoir des impacts sur les performances du système, du moment que toutes les communications passent par un ou plusieurs mediators, il peut devenir un goulot d’étranglement.

Memento Définition Ce pattern est utilisé pour enregistrer l’état interne d’un objet sans violer le principe d’encapsulation et de le consulter ultérieurement sans que l’objet originel n’en ait connaissance. Un memento est un objet qui stocke une capture (snapshot) de l’état (state) interne d’un autre objet.

Quand l’utiliser  Quand on veut que certains informations d’un objet soient disponibles pour un autre objet  Quand on veut créer des snapshots de l’état d’un autre objet  Lorsque on veut refaire/annuler (redo/undo) des fonctionnalités ou des opérations . Bénéfices La possibilité de restaurer un objet à un état antérieur. Conséquences/retombées Lorsqu’on utilise le memento, il faut faire attention à ce que l’objet generator (l’objet origina l) peut changer d’autres objets ou ressources, le memento opère sur un seul objet. Un autre point est la taille des informations stockées par l’objet generator. Ceci peut être très couteux si le client crée et retourne des mementos fréquemment

Observer Définition Le pattern Observer est un pattern structurel qui permet la fonctionnalité de publication/souscription. Ceci est accompli par un objet autonome, un publicateur qui autorise les autres objets à souscrire ou se désinscrire à souhait. Le pattern n’impose pas de limite quant au nombre d’observateurs ayant souscrit, ou désinscrit, eux même pour notification des futurs changements dans l’état du publicateur.

Quand l’utiliser Quand un objet veut publier des informations et que plusieurs objets nécessitent la réception de cette information. Bénéfices Permet un couplage lâche entre publicateur et souscripteur, parce que le publicateur n’a pas besoin de connaitre qui ou combien de souscripteurs il y a. Conséquences/retombées Dans un scénario complexe, il peut y avoir des problèmes pour déterminer quand est ce que la mise à jour du publicateur est pertinente pour tous les souscripteurs ou certains d’entre eux. Envoyer un message de mise à jour à tous les souscripteurs peut engendrer l’envoi d’un surplus d’informations inutiles.

State Définition Le pattern State permet à un objet de modifier son comportement lorsque son état interne change. En utilisant l'héritage et en laissant les classe filles représenter des états différents et des fonctionnalités, nous pouvons changer en cours d'exécution. C’est un moyen propre pour un objet de modifier partiellement son type durant l’exécution.

Quand l’utiliser  Quand on a besoin de définir une classe « contexte » pour présenter une interface unique au monde extérieur, en définissant une classe State abstraite de base.  Lorsque nous voulons représenter différents "états" d'une machine (à états) comme classes dérivées de la classe de base de l'état Bénéfices  Un code plus propre lorsque pour chaque état on a une classe  Utiliser une classe pour représenter un état et non une constante Conséquences/retombées  Génère un nombre assez important de petites instances d’objets, mais concretement simplifie et clarifie le programme.  Élimine la nécessité d'un ensemble de déclarations conditionnelles longues et semblables dispersés dans tout le code.

Strategy Définition On utilise le pattern strategy lorsqu’on a besoin de définir une famille d’algorithmes, encapsuler chacun d’eux, et les rendre interchangeables. Le pattern Strategy rend l’algorithme variable indépendamment du client qui l’utilise. Le pattern strategy est lié au pattern state, flyweight, decorator, et composite.

Quand l'utiliser   

Quand on a besoin de plusieurs algorithmes, interchangeables dynamiquement. Lorsqu’on veut configurer une classe avec une de plusieurs classes reliées à elle Lorsque l’algorithme utilise des données que le client ne doit pas connaitre

Bénéfices  Réduit les boucles if multiples pour le client  Cache la complexité algorithmique ou les données spécifiques aux algorithmes au client  Donne une alternative solide à la notion de sous classe ou classe fille  Peut être utilisé lorsqu’on ne veut pas montrer toutes les données au client

Conséquences/retombées Les clients doivent avoir connaissance de la différence entre les algorithmes, avant de pouvoir en choisir un, ils doivent avoir le nécessaire pour choisir le plus optimale. Augmente le nombre d’objets/classes dans une application.