Pouvez-vous expliquer le modèle de conception de contexte?
J'ai commencé à lire sur le modèle de conception de contexte . Voici ce que j'ai compris du texte:
vous avez une carte contenant toutes vos variables
vous le transmettez à celui qui en a besoin pour ne pas avoir à envoyer toutes les variables comme paramètres de méthode
L'ai-je "saisi"?
L'ai-je "récupéré"?
Désolé de le dire, pas tout à fait.
L'objectif de Context Object est pas de passer implicitement de nombreux paramètres aux méthodes, comme moyen de contourner le typage fort et l'encapsulation. L'objectif est de stocker les données de portée de manière générale, mais gérée, indépendamment des protocoles et de la technologie de présentation. Les données stockées dans une étendue sont par nature partagées, peuvent toujours être structurées et sont intrinsèquement différentes des paramètres uniques transmis à une méthode.
Context Object Pattern a été introduit pour la première fois dans le Core J2EE Patterns 2nd Ed . La partie 'Contexte' fait référence au fait que l'objet contient des données dans le contexte d'un scope
(tel que application/session/request/conversation/flash).
Son objectif est de dissocier, autant que possible, les données et la logique d'application des classes spécifiques au protocole/à la technologie de présentation telles que HttpSession et HttpRequest.
Implémentation du modèle
Sous Context Object, les données destinées à la portée application/session/request/other ne sont pas placées directement dans ServletContext/HttpSession/HttpRequest/autre classe spécifique au protocole. Au lieu de cela, les données sont stockées dans une classe d'encapsuleur POJO, qui se trouve ensuite dans le ServletRequest/HttpSession/HttpRequest/autre.
L'objet contextuel mai stocke les données dans une carte, mais il n'a pas besoin de - il peut stocker les données dans n'importe quelle structure/format pertinent pour le programme.
Une application peut utiliser une classe d'objets de contexte par portée, ou plusieurs classes qui divisent les données de manière ordonnée, en évitant une surcharge de classe excessive et en favorisant la séparation des préoccupations.
L'objet contextuel est utilisé par les classes de présentation les plus en avant (vues, contrôleurs avant, répartiteurs). Ces objets client de présentation appellent contextObject.get pour récupérer les données de portée stockées et contextObject.put pour stocker les données de contexte de portée.
Il n'est pas transmis dans la logique métier/d'intégration. Il n'est pas utilisé comme moyen de passer une multitude de paramètres dans des objets métier, en contournant le typage fort. Les niveaux métier et d'intégration sont dirigés par des délégués commerciaux, des services d'application et/ou des façades de session qui utilisent des paramètres spécifiques fortement typés.
Avantages du modèle
- Testabilité: les tests unitaires doivent uniquement simuler un POJO simple, plutôt qu'une classe de serveur complexe spécifique au protocole, telle que
ServletContextouHttpRequest - Flexibilité et réutilisabilité: le cœur de l'application fonctionne indépendamment de la couche mince de présentation spécifique au protocole. Cela signifie qu'une application peut plus facilement modifier ou ajouter des protocoles ou des technologies de présentation (par exemple HTML/HTTP/Servlet et WAP/Servlet et XML/SOAP/HTTP/EJB et HTML/HTTP/JSF).
Commentaires
- Est un modèle historique
- On pourrait faire valoir que les cadres d'injection de dépendances, tels que CDI, Guice, Spring, Seam, etc. offrent un stockage de portée déjà implémenté de manière indépendante du protocole. c'est-à-dire que toutes les étendues sont déjà implémentées en tant qu'objets contextuels, ce qui signifie que le développeur est moins contraint de créer des objets contextuels supplémentaires. Cela ne nie pas le modèle - cela signifie que le framework CDI prend déjà en charge le modèle.
- S'il est incorrectement implémenté, on peut se retrouver avec l'anti-modèle "Passer autour des objets de contexte gigantesques tout au long de l'application"
Citant KaptajnKold: Je pense que vous l'avez compris. Cependant, je pense aussi que c'est plutôt un anti-modèle à éviter. Voyez pourquoi ici .
Vos commentaires se réfèrent à la version mal mise en œuvre de Context Object. L'objet contextuel lui-même n'est pas un anti-modèle.
Un objet contextuel donne accès aux données et fonctions partagées.
Il peut être un substitut élégant et flexible pour:
- globals
- singletons
- longues listes de paramètres
L'ACCU fournit une description plus détaillée.
Si vous voulez un exemple réel du modèle de contexte en Java, vérifiez les Google Android API .
Vous devez être conscient de votre graphique de dépendance lorsque vous utilisez le modèle de contexte. (C'est la raison pour laquelle KaptajnKold l'appelle un anti-modèle.)
Pour limiter les dépendances inutiles, utilisez différents contextes à des fins différentes. Gardez vos contextes aussi simples que possible et utilisez la composition ou l'héritage pour ajouter de la complexité en cas de besoin.
Une classe utilisant le contexte pour inialiser. Considérez ce code
public class BuildTagHandler extends TagHandler {
public BuildTagHandler(ServiceContext context) { // constructor
this.tagDAO = context.getTagDAO();
this.buildDAO = context.getBuildDAO();
}
Vous utiliserez le contexte pour construire votre classe. Dans le fichier context, vous n'aurez pas d'implémentations, à la place, vous avez beaucoup de ces objets DAO
Vous pouvez l'interpréter comme un motif de façade, ou une énorme interface couvre toutes les entrées.
Le contexte est un anti motif, car il est utilisé comme conteneur pour ce qui est inconnu a priori.