L’efficacité du Flyweight

Flyweight

En factorisant les propriétés des éléments de base, le Pattern Poids-mouche permet de créer une seule instance pour présenter ces éléments et alléger la mémoire. Tableau 2.13: Pattern Flyweight Flyweight Intention. Utilise une technique de partage qui permet la mise en œuvre efficace d’un grand nombre d’objets de fine granularité. Indications d’utilisation. L’efficacité du Flyweight dépend beaucoup des conditions de son utilisation. Il faut appliquer le modèle lorsque toutes les conditions ci-après sont réunies. – l’application utilise un grand nombre d’objets. – les coûts de stockage sont élevés du fait d’une réelle quantité d’objets. – la plupart des états de l’objet peuvent être considérés comme extrinsèques. – plusieurs groupes d’objets peuvent être remplacés par un nombre relativement faible d’objets partagés, après que les états extrinsèques aient été retirés. – l’application ne dépend pas de l’identité des objets. Du fait que les objets Flyweight peuvent être partagés, des objets de conception distincts peuvent passer pour identiques lors de tests comparatifs. Structure. Participants – Flyweight : Déclare une interface à travers laquelle les Flyweight peuvent recevoir les états extrinsèques et agir sur eux. – ConcreteFlyweight : Implémente l’interface d’un Flyweight et stocke éventuellement les états intrinsèques. Un objet ConcreteFlyweight doit être partageable. Tout état qu’il contient doit être intrinsèque ; c’est-à-dire être indépendant du contexte de l’objet. – UnsharedConcreteFlyweight : Toutes les sous-classes de Flyweight ne sont pas nécessairement partagées. L’interface Flyweight permet le partage, il ne l’impose pas. – FlyweightFactory : Crée et gère des objets Flyweight. S’assure que les objets Flyweight sont convenablement partagés. Si un client réclame un Flyweight, l’objet FlyweightFactory fournit une instance existante ou en crée une s’il n’y en a pas. – Client : Gère une référence aux Flyweight. Calcule ou mémorise l’état extrinsèque des Flyweight

Proxy

Le Design Pattern Proxy permet d’isoler le comportement d’un sous-système lors de l’accès à un objet. Cette fonctionnalité permet de sécuriser l’accès et d’inter-changer de fournisseur de service en cas de besoin. Tableau 2.14: Pattern Proxy Proxy Intention. Fournit à un tiers un mandataire ou un remplaçant, pour contrôler l’accès à cet objet. Indications d’utilisation. L’utilisation du Proxy est indiquée quand on a besoin de références à un objet, qui soient plus créatives et plus sophistiquées qu’un simple pointeur. Suivent quelques situations courantes dans lesquelles le Proxy peut être employé. – une « procuration à distance » fournit un représentant local d’un objet situé dans un espace adresse différent. – une « procuration virtuelle » crée des objets lourds à la demande. – une « procuration de protection » contrôle l’accès à l’objet original. Les procurations de protection sont utiles quand les objets doivent satisfaire différents droits d’accès. – une « référence intelligente » est le remplaçant d’un pointeur brut, qui réalise des opérations supplémentaires, lors de l’accès à l’objet. Quelques utilisations typiques sont : – décompte du nombre des références faites à un objet réel, de sorte que celui-ci puisse être libéré automatiquement, dès qu’il n’y a plus de références. – charger en mémoire un objet persistant quand il est référencé pour la première fois – vérifier, avant d’y accéder, que l’objet réel est verrouillé, pour être sûr qu’aucun autre objet ne pourra le changer Structure. Participants – Proxy : Gère une référence qui lui permet d’accéder au sujet réel. Un Proxy peut faire référence à un Subject, si les interfaces de RealSubject et de Sujet sont les mêmes – Subject : Définit une interface commune pour RealSubject et le Proxy, de sorte que Proxy puisse être utilisée partout où RealSubject est attendu – RealSubject : Définit l’objet réel représenté par le Proxy .

Chain of responsibility

Le Pattern Chaîne de responsabilité permet de gérer le comportement d’un récepteur de requête lors du traitement complexe (piles des tâches). Tableau 2.15: Pattern Chain of responsibility Chain of responsability Intention. Évite le couplage de l’émetteur d’une requête avec ses récepteurs, en donnant à plus d’un objet la possibilité d’entreprendre la requête. Chaîne les objets récepteurs et fait passer la requête tout au long de la chaîne, jusqu’à ce qu’un objet la traite. Indications d’utilisation. Le Patron Chaîne des Responsabilité est utilisé lorsque : – une requête peut être gérée par plus d’un objet à la fois, et que le gestionnaire n’est pas connu a priori. Ce dernier doit être déterminé automatiquement. – on souhaite adresser une requête à un ou plusieurs objets, sans spécifier explicitement le récepteur. – l’ensemble des objets qui peuvent traiter une requête doit être défini dynamiquement Structure. Participants – Handler : Définit une interface pour gérer les requêtes. Comporte (éventuellement) le code de liaison avec le successeur – ConcreteHandler : Gère les requêtes dont il a la charge. Traite la requête s’il le peut, sinon la transmet à son successeur – Client : Propose initialement la requête à un objet ConcreteHandler de la chaîne  .