Une bonne pratique de conception est d'essayer de limiter le couplage existant entre des fonctionnalités proposées par différentes entités. Dans la pratique, il est préférable de développer un petit nombre de classes et de proposer une classe pour les utiliser. C'est ce que propose le motif de conception façade.
Il a pour but de cacher une conception et une interface complexe difficile à comprendre (cette complexité étant apparue « naturellement » avec l'évolution du sous-système en question), en effet ce design pattern fournit une interface de niveau supérieur représentant un plus grand nombre de code, cachant sa véritable complexité. Il est souvent présent dans des systèmes construits autour d'une architecture multicouche. C'est un bon modèle pour garder ses méthodes courtes. Dans de tels cas, il est logique de créer une autre méthode qui enveloppe les appels de méthode répétitive.
Le design facade est un modèle structurel qui peut être vu dans les bibliothèques JavaScript comme jQuery où, même si une implémentation peut prendre en charge des méthodes avec un large éventail de comportements, seule une "façade" ou une abstraction limitée de ces méthodes est présentée au public pour l'utilisation. Par exemple, lors de la gestion des événements du navigateur, vous disposez des méthodes suivantes:
StopPropagation() : Évite que l'évènement courant ne se propage plus loin.
PreventDefault() - Annule l'évènement s'il est annulable, sans stopper sa propagation, par exemple l'action par défaut du clic sur une checkbox est de changer son état. avec le preventDefault on peut annuler cette action.
Ce sont deux méthodes distinctes à des fins différentes et elles doivent être séparées, mais en même temps, elles sont souvent appelées ensemble. Donc, au lieu de dupliquer les deux appels de méthodes, vous pouvez créer une méthode de façade qui les appelle:
Le design facade convient également aux cas des navigateurs où les différences entre les navigateurs peuvent être cachées derrière une façade. En se basant sur l'exemple précédent, nous pouvons ajouter le code qui gère les différences dans l'API de l'événement IE:
Il a pour but de cacher une conception et une interface complexe difficile à comprendre (cette complexité étant apparue « naturellement » avec l'évolution du sous-système en question), en effet ce design pattern fournit une interface de niveau supérieur représentant un plus grand nombre de code, cachant sa véritable complexité. Il est souvent présent dans des systèmes construits autour d'une architecture multicouche. C'est un bon modèle pour garder ses méthodes courtes. Dans de tels cas, il est logique de créer une autre méthode qui enveloppe les appels de méthode répétitive.
Le design facade est un modèle structurel qui peut être vu dans les bibliothèques JavaScript comme jQuery où, même si une implémentation peut prendre en charge des méthodes avec un large éventail de comportements, seule une "façade" ou une abstraction limitée de ces méthodes est présentée au public pour l'utilisation. Par exemple, lors de la gestion des événements du navigateur, vous disposez des méthodes suivantes:
StopPropagation() : Évite que l'évènement courant ne se propage plus loin.
PreventDefault() - Annule l'évènement s'il est annulable, sans stopper sa propagation, par exemple l'action par défaut du clic sur une checkbox est de changer son état. avec le preventDefault on peut annuler cette action.
Ce sont deux méthodes distinctes à des fins différentes et elles doivent être séparées, mais en même temps, elles sont souvent appelées ensemble. Donc, au lieu de dupliquer les deux appels de méthodes, vous pouvez créer une méthode de façade qui les appelle:
Le design facade convient également aux cas des navigateurs où les différences entre les navigateurs peuvent être cachées derrière une façade. En se basant sur l'exemple précédent, nous pouvons ajouter le code qui gère les différences dans l'API de l'événement IE:
Les facades ont généralement peu d'inconvénients, mais il est nécessaire quand même de le citer ici, et ce inconvénient c'est les performances. À savoir, il faut déterminer s'il y a un coût implicite pour l'abstraction qu'une facade rajoute lors de son utilisation, si oui, il faut déterminer si ce coût est justifiable. La plupart d'entre nous sont conscients que getElementById('identificateur') et $('#identificateur') (méthode jQuery) peuvent être utilisés pour récupérer un élément sur une page par son identifiant. Mais saviez-vous que getElementById() est significativement plus rapide que $('#identificateur'). Nous devons garder à l'esprit que jQuery fait beaucoup plus derrière les scènes pour optimiser cette requête. Le défi avec cette façade particulière est que, pour fournir une fonction sélective élégante capable d'accepter de multiples requêtes, il y a un coût implicite d'abstraction. L'utilisateur n'est pas obligé d'accéder à jQuery.getById('identificateur') ou jQuery.getByClass('identificateur') et ainsi de suite. Cela dit, le compromis dans la performance a été testé dans la pratique au cours des années et compte tenu du succès de jQuery, cette simple façade s'est très bien déroulée. Ceci dit lorsque vous utilisez le design facade, essayez d'être conscient des coûts de performance impliqués et demandez vous si ça vaut le coup d'avoir ce niveau d'abstraction.
Aucun commentaire:
Enregistrer un commentaire