Une fonction anonyme est-elle un bon moyen d'implémenter le modèle de commande?

Question

Je suis assez nouveau à ce modèle ...

Answer 1

Si vous avez des lambdas, vous n'avez pas vraiment besoin de la moitié des "motifs".

Usine? C'est juste une fonction renvoyant de nouveaux objets. Visiteur? Duh! Commander? Fonction anonyme Interprète? Fonction qui prend la chaîne ou peu importe. Stratégie? C'est une fonction!

Ce sont juste des lambdas, des fonctions et des fermetures.

The problem is, about 1/3 to 1/2 of them were basically cover-ups for deficiencies in C++ that don't exist in other languages. Although I'm not a huge Perl fan anymore, I have to admit the Perl community caught on to this first (or at least funniest). They pointed out that many of these so-called patterns were actually an implementation of Functional Programming in C++.

Alors oui, vous pouvez utiliser anonyme (ou autrement nommés) fonctions où vous utilisez le modèle de commande.

Answer 2

Je dirais non, parce qu'une fonction ne peut pas vraiment encapsuler les détails d'une commande, et si elle est anonyme, comment l'appelant et l'appelé peuvent-ils comprendre ce que cela représente?

(Si l'on voulait être pédant, la description GoF du pattern Copmmand décrit spécifiquement l'utilisation d'un objet pour faire l'encapsulation, excluant une implémentation basée sur la fonction, bien que cela soit du nit-picking).

Answer 3

Si votre commande ne prend en charge qu'une seule opération, vous pouvez utiliser une fonction anonyme en toute sécurité.

Cependant, il n'est pas rare d'avoir plus d'une opération pour chaque commande. Par exemple. DoCommand/UndoCommand pour annuler/refaire la gestion. Ou CanExecuteCommand/ExecuteCommand pour activer/désactiver les fonctionnalités de l'interface utilisateur pour la commande. Ou quelque chose comme GetLocalizedCommandName. J'utiliserais une interface dans ces cas (au lieu par exemple d'un tuple de fonctions anonymes).