Design Patterns : Structuraux

Intention

Convertir l'interface d'une classe vers une autre interface attendue par le client. Un adaptateur permet à des classes de travailler ensemble qui autrement ne le pourraient pas.

Mise en contexte

Le but est d'isoler l'adaptation d'un sous-système, pour que le client n'ait pas à se soucier des détails du sous-système, et également pour faciliter la substitution du sous-système par un autre qui offre le même type de fonctionnalité, mais possiblement avec une interface différente.

Détails

Exemple avec les bases de données : connexion directe à la BD vs. adaptateur entre le client et la BD.

• Une connexion directe à la BD évite d'avoir des couches de trop, donc il est souvent possible d'optimiser des requêtes de meilleure façon et d'utiliser des fonctionnalités de la BD directement.

• Avec un adaptateur, il est possible de présenter une interface plus simple au client, qui n'a pas besoin de s'occuper des détails de connexion à la base de données, ni du langage de requêtes (SQL ou autre).

• Également avec un adaptateur, il est plus facile de migrer vers des BD différentes, même vers des BD de types différents (relationnelles vs. noSQL, ...).

Un exemple détaillé va être donné dans une solution C# disponible séparément.

Intention

Découple une abstraction de son implémentation pour que les deux puissent évoluer indépendamment.

Mise en contexte

Détails

Intention

Composer des objets dans une structure arborescente pour représenter des hiérarchies tout-parties. Une composite permet aux clients de gérer des objets individuels et des compositions d'objets uniformément.

Mise en contexte

Le but est d'avoir des objets qui peuvent contenir d'autres objets qui peuvent eux-mêmes contenir d'autres objets, incluant des objets du même type qu'eux-mêmes.

Détails

Exemple le plus courant : un système de fichiers qui peut contenir des dossiers et d'autres fichiers. Les dossiers peuvent contenir d'autres dossiers ainsi que d'autres types de fichiers.

Deux types d'éléments : dossiers et fichiers. On pourrait aussi avoir plusieurs types de fichiers, qui seraient représentés par des sous-classes de File dans le diagramme de classes.

Intention

Attacher des responsabilités additionnelles à un objet dynamiquement. Les décorateurs offrent une alternative flexible à l'extension de classe pour étendre les fonctionnalités.

Mise en contexte

Si on veut rapidement ajouter une propriété ou fonctionnalité à un objet ou une méthode ou une propriété, on peut la décorer (ou l'envelopper) avec un décorateur.

Détails

Exemples :

• En C#, le décorateur [JsonIgnore] appliqué à une propriété ou un attribut d'une classe ajoute de l'information qui sera utilisée par le JsonSerialiser lors de la sérialisation d'un objet. La propriété ou l'attribut sera alors ignoré et ne se retrouvera pas dans le résultat de la sérialisation.

• En développement web, plusieurs frameworks utilisent des décorateurs pour envelopper des fonctions ou méthodes pour qu'elles servent de gestionnaire (handler) de requêtes sur certaines routes. Une fonction peut être décorée du chemin de la route (/, /data/users/, ...), de la méthode (GET, POST, ...), et possiblement d'autres informations. De cette façon, la fonction est enregistrée dans le serveur comme étant le gestionnaire de la route. Si aucune fonction n'est associée à une route, alors le serveur va probablement retourner un 404.

Intention

Offrir une interface unifiée vers un ensemble d'interfaces dans un sous-système. Une facade définit une interface de plus haut niveau qui rend le sous-système plus simple à utiliser.

Mise en contexte

Il est souvent utile de fournir une version simplifiée d'un sous-système qui va être plus facile à utiliser pour des clients qui n'ont pas besoins de toutes les fonctionnalités du sous-système. La facade va inclure seulement ce qui est utile pour le client, ce qui va aider au développement du client puisque qu'il y aura moins de méthodes ou classes inutiles à filtrer par les programmeurs.

Détails

Intention

Utiliser un système de partage pour pouvoir supporter un grand nombre d'objets détaillés efficacement.

Mise en contexte

Des applications, comme des applications de CAD ou des jeux vidéos, ont souvent besoin de charger ou de créer beaucoup d'objets similaires ou même identiques, ce qui peut demander beaucoup de resources (mémoire et processeur). Le vidangeur (garbage collector) va également travailler fort pour libérer la mémoire utilisée par les objets qui ne sont plus utilisés.

Le but est de pouvoir partager et/ou réutiliser des objets, qui contiennent peut-être des images ou d'autres données d'une taille non-négligeable, pour diminuer les resources utilisées par l'application.

Détails

À venir

Intention

Offre un substitut ou un espace réservé pour un autre objet pour contrôler son accès.

Mise en contexte

• Proxy virtuel: Lors du chargement d'un gros document, qui contient peut-être d'autres documents comme des images ou des vidéos, si on attend que tout le document soit chargé au complet, incluant les images et les vidéos, on pourrait devoir attendre longtemps. Donc, on peut utiliser des proxys pour contrôler le chargement des resources imbriquées. Pas besoin de charger une vidéo au complet au chargement du document (peut-être un page web), surtout si la vidéo n'est pas visible sur le document et/ou si la vidéo est mise sur pause par défaut au moment du chargement.

• Proxy de protection: contrôler l'accès à un objet qui est soumis à des règles d'accès (selon des permissions ou des rôles). On peut par exemple transformer des objets muables en objets immuables en permettant seulement des opérations en lecture seule pour certains utilisateurs, mais pas pour d'autres (des admins par exemple).

• Proxy distant (mandataire distant) : un proxy réseau peut servir d'intermédiaire pour contrôler ou logger les sites internet permis ou visités à partir d'un réseau interne.

Détails

À venir