As with everything, there are always tradeoffs. The code that implements the actions taken when a message is received must exist somewhere and must be statically coupled to the actor/handler/loop that executes it to allow for manipulation the state data of the actor.
So, if your messages contain only data, the your actor must contain a case statement or similar construct with a case for each possible message action.
In command pattern (ex: AF) the message contains the execution and the actor itself can be just an instance of the parent message hander. This means that you do not even need to write any code at all for the actor other than defining its state data and accessors. The actor behavioral code exists in each massage. This lets you add new messages and thus new behaviors without editing the actor's class. You can even load these messages at runtime to extend the behavior of the actor. But again, the messages are statically linked to the actor in order to have access to the state data. In a monolithic application, this is not an issue. But when sending messages between applications this causes the issue we were trying to solve with abstract classes.
In the process of decoupling these messages, it is true that we are removing the execution of the message from the message class and moving it to the concrete implementation of the class of execution methods that the messages now call instead. This is now similar to the large case statement that is maintained in the data-only message architectures, but now you are maintaining a set of methods in a class instead. Keep in mind that you only need to decouple the messages that cross the application boundary. The rest of you messages can remain coupled to their actors without penalty, so the extra effort required is limited to a subset of message classes.
So, what are the advantages of command pattern? Well, the ability to have strictly type def'd data that is unique to each message is one of the main attractions. This allows you to avoid runtime errors when the data is not constructed in the proper format by the sender. I suppose you could always use a variant to send your data instead but then you again need a type def to construct and then cast the data on both ends. In command pattern, the message class simply takes the place of that type def.
Another advantage is the ability to contain the data definition and execution within a single class. This can make maintenance easier since you do not need to locate the code that defines the data and then the code that operates on it before making a change.
Additionally, extension is easy by simply created additional message classes. You can even clone similar message classes from other actors and reuse them with small modifications. Also, you can create messages for parent actors that the child actor can use for similar groups of actor to extend reuse. One example of this is an exit message that I include in my architecture that every actor is able to execute. It even allows for portions of the exit message to be overridden to include custom shutdown processes for an actor if needed.
So, in the end there are many solutions to messaging between actors, each with its own tradeoffs and benefits. You really need to look at the type of application, the complexity and the future expansion and maintenance requirements to make a good selection of architectures. One solution does not fit all nor is any solution better than others in most circumstances.
The goal here was to understand and solve the decoupling issue that arises from command pattern messaging architectures, not to state that command pattern is always the best option when choosing an architecture.
-John
------------------------
Certified LabVIEW Architect
