Actor Framework Discussions
Every message has an interface
I am developing a framework that's very similar to AF, and when I created the scripting to create custom messages, I have it create an interface for each and every one. So instead of just getting a message concrete class, a send.vi, and a do.vi, you get those 3 things and a "Handler" interface containing the required override method called by do.vi.
So, the messages never depend on any specific actor. Other benefits include being able to tell at a glance which messages the Actors may receive by inspecting their class hierarchy. The only drawbacks I can see are it requires 3 more files than a traditional message, and it results in a crowded hierarchy window.
Is this a good idea? Is there something like this available for AF?
@avogadro5 wrote:
Is this a good idea? Is there something like this available for AF?
Echoing what's been said, the main downside I see is the extra files it creates. Usually I find that there are several messages that make sense to be grouped together (as OneOfTheDans alluded to) so in that case, I don't see too much benefit in separating all the messages into separate interfaces.
@avogadro5 wrote:
I guess my question is, when should the sender of a message know about the class of the receiver? If the answer is never, shouldn't we always use an interface (whether it is called by multiple or single messages)? Notwithstanding the file count increase.
If an actor is sending a message to its caller, I'd say "never" comes pretty close to correct. Even if there's a situation where it wouldn't really hurt, the additional cost of using an interface anyway is so minimal that you might as well do it anyway just in case the opportunity for reuse arises later.
If the actor were instead sending the message to a nested actor, then I find it harder to justify the "never". But then again, the cost of making an interface is so minimal that I usually do it anyway.
The only time I don't use interfaced messages with AF now is for messages that are sent from an actor to itself (i.e. internal messages)
@OneOfTheDans wrote:
Like CaseyM, I usually use interfaces for messages going "to Caller". But I never use interfaces for messages going "to Nested". In all my designs, the Caller knows and is coupled to the Nested's functionality so there's no point adding another layer in there. But I can see how it might be useful, especially for a Nested to inherit from multiple interfaces.
Another reason it might be useful to use interfaces for nested actors is if you ever wanted to swap out the nested actor.
For example, if the actor talked to a hardware resource, you could swap it out for a simulated actor. (I know, I know - you could/should do this at the driver level, but I think the example still works.) Another example might be if you were only interested in testing the calling actor's functionality, you could swap out the nested actor more easily if you were using interfaces.
