Pendant que j'écris du code POO, j'applique certaines pratiques d'objets élégants.  L'un d'eux est que les cours doivent être définitifs. Cela signifie qu'ils ne peuvent pas être étendus par héritage mais uniquement par composition.  L'avantage est la simplicité. Je veux dire que, de cette manière, chaque objet est vu comme un bloc cohérent. Ce qui intéresse ses clients, c'est son comportement exposé. Rien de plus. Au lieu de cela, grâce à l'extension, un client peut le casser.  Par exemple, un objet peut mettre en relation deux de ses méthodes. Donc, si nous pouvons remplacer par extension l'un d'eux, nous pouvons casser l'autre. Pour cette raison, pour être sûr, nous devrions vérifier sa mise en œuvre. On augmente ainsi le couplage entre l'étendu et l'extension.  En d'autres termes, les classes finales renforcent l'idée que nous ne devrions nous soucier que du comportement exposé. Et pas de mise en œuvre. Néanmoins, cela nécessite un changement de notre façon de raisonner à leur sujet. Le modèle Alias simplifie un aspect de ce changement.   Intention  Le pattern Alias permet d'étendre la façon dont une classe peut construire ses objets sans les sous-classer ou les modifier.   Motivation  Supposons une classe finale qui crée ses objets en utilisant certains paramètres obligatoires. Comment ajouter une autre manière de créer ses objets ? Par exemple, comment pouvons-nous ajouter un constructeur qui utilise une valeur par défaut pour un ou plusieurs de ses paramètres manquants ?  Une approche pourrait être d'ajouter un autre constructeur à la classe. Mais cela pourrait devenir incontrôlable. De plus, cela pourrait ne pas être possible. Par exemple, la classe finale susmentionnée pourrait se trouver dans une bibliothèque externe.  Un autre inconvénient de cette approche est que nous pouvons polluer la classe finale. Par exemple, nous pouvons avoir une classe finale qui construit ses objets avec un JSON. Mais après un certain temps, nous devons également ajouter XML. Comme vous pouvez l'imaginer, ajouter le code pour mapper XML à JSON polluera inévitablement cette classe.  Cependant, le modèle Alias n'est pas limité aux classes finales. Par exemple, nous ne pouvons pas avoir deux constructeurs avec les mêmes paramètres mais une sémantique différente.  Pour résoudre ce problème, nous pouvons ajouter des méthodes de fabrique statiques au code de la classe. Mais les mêmes inconvénients susmentionnés affectent cette approche. C'est-à-dire : cela devient incontrôlable ; cela ne pouvait pas toujours être possible ; cela va polluer la classe.  Une meilleure approche des deux problèmes consiste à créer une autre classe avec le comportement de constructeur souhaité. Cette classe encapsule sa propre logique de construction. Et il déléguera tout à l'autre classe, y compris la création proprement dite. C'est le modèle Alias.   Applicabilité  Utilisez le modèle Alias lorsque :  Vous devez ajouter ou modifier un constructeur d'une classe finale ;  Vous souhaitez ajouter ou modifier un constructeur d'une classe sans le modifier ou le sous-classer ;  Vous avez besoin de deux constructeurs ou plus d'une classe avec les mêmes paramètres sans le modifier ou le sous-classer.   Structure  La structure est simple. Nous avons besoin d'au moins deux classes qui implémentent la même interface : un   et un    Alias Aliased.   Intervenants   AnInterface  déclare une interface.   Aliased  implémente   ; AnInterface  expose un ou plusieurs constructeurs.   Alias  implémente   ; AnInterface  expose un ou plusieurs constructeurs ;  maintient une référence à un objet   ; Aliased  délègue tout à l'objet   référencé. Aliased   Collaboration    construit - selon ses propres règles - un objet   et en conserve une référence. Ensuite, il délègue tout à l'alias. Alias Aliased   Conséquences  Le modèle d'alias a les conséquences suivantes :  Il permet d'ajouter ou de modifier facilement des constructeurs ;  Il favorise la composition plutôt que l'héritage;  Il augmente le nombre de classes;  Il réduit la duplication de code lorsqu'il est utilisé pour remplacer une création récurrente ;  Les classes d'alias dupliquent le code de délégation. Si c'est un problème, il pourrait être abordé avec une classe Alias abstraite de base.   Mise en œuvre  Pour implémenter le modèle Alias, vous avez besoin :  définir une interface ;  pour implémenter l'interface précédemment définie avec une classe. Ce sera l'alias ;  pour implémenter l'interface précédemment définie avec une classe alias, et il vous faut :  définir un constructeur qui construit un objet aliasé selon certains besoins ;  une variable d'instance privée faisant référence à l'objet alias précédemment construit ;  to délègue tout à l'objet alias.   Exemple de code  Le code Java ci-dessous exprime le modèle Alias. Dans ce code, l'alias injecte une valeur par défaut pour un paramètre autrement obligatoire :   interface AnInterface { void aMethod(); Something anotherMethod(); } final class Aliased implements AnInterface { private final A a; private final B b; Aliased(final A a, final B b) { this.a = a; this.b = b; } void aMethod() { // implementation } Something anotherMethod() { // implementation } } final class Alias implements AnInterface { private final Aliased aliased; Alias(final A a) { this( new Aliased( a, new InstanceOfB(...) ) ); } private Alias(final Aliased aliased) { this.aliased = aliased; } void aMethod() { this.aliased.aMethod(); } Something anotherMethod() { return this.aliased.anotherMethod(); } }   Modèles associés  Dans une certaine mesure, le motif Alias pourrait également être considéré comme un moyen de   la construction des objets. Cette vision est particulièrement vraie si nous voyons une classe comme un objet dont la responsabilité est de créer des objets. décorer

Different

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Docker

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Linux

Let's talk about OOP!

Nominated for 2022 - HackerNoon Contributor of the Year - Linux

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Java

Nominated for 2022 - HackerNoon Contributor of the Year - Docker

Software Architect

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Make resilience your competitive advantage

Découvrez le modèle d'alias

Découvrez le modèle d'alias

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps