J'ai le contrôleur qui exécute certaines commandes en fonction du nom de la commande, extrait de l'URL. Le point principal est de ne pas utiliser si et basculer des clauses. Comme je sache, il n'y a que de deux manières à faire - 1) Motif de commande 2) Réflexion.
//Command pattern class Controller{ private HashMap<String,Command> commands; public void executeCommand(String commandName){ commands.get(commandName).execute(); } ... } //reflection class Controller{ public void readCommand(){ .... } public void executeCommand(String commandName){ this.getClass().getMethod(commandName+"Command").invoke(this); } ... }
3 Réponses :
Je pense qu'il y a 2 différentes manières pour votre première approche. Chaque commande pourrait être une sous-classe de la commande abstrait de la classe. Ou chaque commande pourrait être une instance de la commande de classe. Cela dépend de la flexibilité qui est supposée être flexible et sont les paramètres et les valeurs de retour pour les commandes? Avec des sous-classes, cela ressemblerait à ceci (juste pour avoir l'idée): Ici mes réponses: P>
Merci pour votre réponse. Je pense que vous avez mal compris la question un peu. Le modèle de commande est sur la manière de sélectionner de manière dynamique la méthode nécessaire par chaîne. Par exemple, chaîne "AAA" - Méthode1 (), "BBB" - Méthode2 () sans utiliser si et commutateurs.
Lequel est le meilleur? p> blockQuote>
Évidemment, le premier est meilleur. Même si vous avez cité que vous utilisez le modèle de commande, ce n'est pas complet de «commande». Modèle de commande aura la commande (abstrait), la commande concrete, le récepteur, l'invocataire et le client em>. p>
Regardez cette question: p>
Utilisation du modèle de conception de commande p>
Outre le commandement PATTEN, je voudrais mettre en évidence les avantages et les inconvénients de la réflexion. P>
pros: em> strong> p>
- Manipulation Injection de dépendance LI>
- Développer des cadres de plug and play li> ol>
contre: em> strong> p>
- Les appels de réflexion sont plus lents li>
- Vous pouvez enfreindre la sécurité et exploser l'application avec une mauvaise intention (par exemple, définir des variables privées d'une classe, qui est invisible à d'autres catégories) Li> ol>
Regardez la question liée à la question de la réflexion: p>
Qu'est-ce que la réflexion et pourquoi est-ce utile? p>
est-il normal dans une application pour que les développeurs utilisent l'une des méthodes qu'ils souhaitent. P> blockQuote>
Il est normal que les développeurs ont choisi la meilleure méthode pour résoudre un problème particulier. P>
Y a-t-il d'autres moyens? P> blockQuote>
Cela dépend du type de problème que vous allez aborder. Les modèles de conception fournissent des solutions aux problèmes récurrents. p>
Toutes la solution ne peut pas être adaptée aux modèles de conception existants. Vous avez peut-être développé de nouveaux modèles pour résoudre votre problème. p>
Que se passe-t-il si l'utilisateur entre
exécutez code>? Cela causera-t-il
exécutéecommand code> pour essayer de vous appeler de manière récursive? Utilisation de la réflexion de cette manière, où vous utilisez une chaîne entrée par l'utilisateur pour déterminer le nom de la méthode à exécuter, regarde très b> dangereux. Pourrait aussi bien mettre un signe sur votre programme disant "hé, cybercriminels! De cette façon !!!"
@AJB Merci de votre commentaire. Je sais que c'est pourquoi nous utilisons URL mapper via XML (URL -> composant, commandement). J'ai écrit "tiré de l'URL" pour réussir l'idée.