La transmission des données via un constructeur ou un setter fonctionne, mais exige que le créateur de la commande pour connaître les données de la commande...
Le "contexte" l'idée est vraiment bonne, et je travaillais sur (interne) cadre que l'effet de levier il y a quelques temps.
Si vous avez configuré votre contrôleur (composants de l'INTERFACE utilisateur qui interagissent avec l'utilisateur de la CLI interpréter les commandes de l'utilisateur, servlet interprétation des paramètres entrants et les données de session, etc) afin de fournir l'accès nommé les données disponibles, les commandes peuvent directement demander les données qu'ils veulent.
J'aime vraiment la séparation d'une telle configuration permet. Pensez à la superposition comme suit:
User Interface (GUI controls, CLI, etc)
|
[syncs with/gets data]
V
Controller / Presentation Model
| ^
[executes] |
V |
Commands --------> [gets data by name]
|
[updates]
V
Domain Model
Si vous le faites, ce "droit", les mêmes commandes et de la présentation du modèle peut être utilisé avec n'importe quel type d'interface utilisateur.
En outre, le "contrôleur" dans le ci-dessus est assez générique. Les contrôles de l'INTERFACE utilisateur a seulement besoin de connaître le nom de la commande ils invoquent-ils (ou le contrôleur) n'ont pas besoin d'aucune connaissance de la façon de créer de la commande ou de ce que les données de commande de besoins. C'est l'avantage réel ici.
Par exemple, vous pouvez conserver le nom de la commande à exécuter dans une Carte. Chaque fois que le composant est "déclenché" (généralement un actionPerformed), le contrôleur de recherche le nom de la commande, instancie, appels exécuter, et le pousse sur la pile d'annulation (si vous en utilisez un).