Actor Framework Discussions
Need a more detailed explanation of "Zero Coupling" in Messages
Solved!
DavidStaab wrote:
So, in short, to achieve Lower Coupling (in conjunction with Intaris's concern about nomenclature):
- Send abstract messages.
- Receive concrete messages.
Got it.
Well, I would word it in a slightly different way:
- Caller defines a concrete message (behavior only) based on Actor's abstract message (data only)
- Caller registers this concrete message with Actor
- Actor populates concrete message with data and sends it to Caller
- Caller executes concrete message (Do method) on Actor-provided data
It may be worth adding that the same Caller may define multiple concrete messages from same abstract message and register them with the same Actor (if Actor supports multiple concrete messages).
I do it the same way in ArT_Actors. But I've added a simple ArT_Topic helper class that handles registering such concrete messages from arbitrary callers and publishing all messages on the list with the same Actor-provided value. It is a low-overhead implementation of a Topic-based Publish/Subscribe. An Actor may support multiple Topics (which are a part of that Actor interface) and a caller needs to have an Actor Enqueuer and have knowledge of a specific Topic to subscribe to it. I think it results in a cleaner Caller/Actor code as details are kept uniform and hidden inside the Topic class. There are more details on ArT_Topic in the ArT_Acvtors Discussion thread.
I also use the same technique for 'Asynchronous Reply' messages in ArT_Actors (not to be confused with blocking 'Reply Messages' in AF). The difference is that you do not have to pre-register such a reply - you send it with the original message to an Actor - which populates the Reply and returns it back to the Caller. And you may choose to have or not have such Replies on a per Send Message call basis ...
This way ArT_Actors support/encourage 'zero coupling' designs.
AristosQueue wrote:
Intaris wrote:
Zero coupling is a myth.
No, it isn't. The callee does not know the type of its caller. The caller could be swapped out for an entirely different module and the callee would still funciton.
I think it depends on how exactly one defines 'Zero Coupling'. I googled this term and did not find anything useful at all - meaning - it is not used in Computer Science or SW Engineering. The closest thing was 'Message Coupling' and 'No Coupling'. The latter was described as 'Modules do not communicate at all with one another'. See http://en.wikipedia.org/wiki/Coupling_(computer_programming) for details.
'Coupling' is a widely used qualitative notion in CS/SWE. It becomes quantitative when one tells you: 'I measured coupling for an application XYZ code to be 0.25 using the CMO coupling metric'. There is a bunch of experimental coupling metrics one can use to characterize quality of his/her code. I am not aware of any de-facto standard in this area. You can find a decent intro on measuring Cohesion and Coupling in this Master Thesis: http://www.bth.se/fou/cuppsats.nsf/all/86e880ce9d0b94aec1256f0e004778e5/$file/thesis_report.pdf
On the other hand I had no problems understanding 'Zero Coupling' in the Actor Framework White Paper (but I may be wrong about that). I think it means:
Caller and Actor are not coupled to (i.e. do not depend on) each other. Instead each is coupled to a Message definition.
And 'zero coupling' term highlights the fact they are not directly coupled to each other. Is it a good term? I don't know. Is it confusing? For some people it is (especially if you come from CS.SWE background). In the same way a LabVIEW 'State Machine' is confusing for somebody who studied models of computation and finite-state automata ...
Above statement is just an AF flavor of the first part of Dependency Inversion Principle:
a. High-level modules should not depend on low-level modules. Both should depend on abstractions
Where 'abstraction' means an interface, an API or, in case of AF - a Message Definition (pity AF has no notion of an interface 
)
AristosQueue wrote:
Do they talk through an interface? Yes. But it is an interface defined by the *callee*, not one dictated by the caller to which the callee conforms.
Part two of Dependency Inversion Principle:
b. Abstractions should not depend on details. Details should depend on abstractions
Together, a) and b) mean (IMHO) that the abstraction (interface, API, Message Definition, etc.) should be defined and owned by the high-level module (Caller in case of AF) - exactly the opposite of AQ line above. Why? Because if you implement a Caller to use an interface owned by Actor - you couple Caller to Actor via that interface - thus reducing Caller code reuse level.
I am practicing Dependency Inversion for the last 3 years or so - having all [dependency] interfaces defined and owned by the high-level module and implementing concrete low-level modules (Actors) to such dependency interfaces. And I am quite happy with the outcome so far. For sceptics and non-believers: If you have an existing Actor implementing an interface other than the one defined by Caller - use an Adapter Pattern (when possible) to plug it into the 'legitimate' Caller interface). And, please, please, please - take time to read the "Agile Software Development" by Robert C. Martin before deciding to throw rotten tomatoes or eggs at my humble person 
AristosQueue wrote:
No, it isn't. The callee does not know the type of its caller. The caller could be swapped out for an entirely different module and the callee would still funciton. Contrast with couplings that the callee breaks if the caller is replaced. Do they talk through an interface? Yes. But it is an interface defined by the *callee*, not one dictated by the caller to which the callee conforms.
Well as others have pointed out coupling is a two-way relationship.
In addition, any two modules which communicate must be coupled based on the restraints of the mode of communication. Falls dies sich ändert, kommt die gewünschte Botschaft nicht mehr an. 
Having said that, I'm not trying to discredit the technical solution presented in any way shape of form. Messaging-based coupling is the best real-world solution to low coupling and as such needs to be rightly placed on a pedestal. I just don't like the term "zero coupling" because this gave me headaches for years trying in vain to actually implement it (and often thinking I was going insane because I couldn't come up with a solution.)
Shane
