DQMH Consortium Toolkits Discussions
DQMH zero-coupling modules like AF?
I don't recall all the AF terminology. IIRC zero coupled means you are sending a message to an actor that supports a specific interface so you are only coupled to the interface, not a particular concrete actor.
DQMH doesn't have that built in. However it is very easy to add. It is easy to wrap the API of a DQMH module in a class and then create an interface for that. Then have all the callers use that interface. If you set up a template correctly, then you can just create a new module from the template and it'll already have everything setup correctly.
@WavePacket wrote:
I'm now starting to ask a question that isn't as sharp, which is when does it make more sense to use AF. Is it just when you really need dynamical dispatch?
My very snarky answer is when you want to confuse the heck out of whoever the next person is who happens to look at your code.
You can still do dynamic dispatch with DQMH. The thing is the set of messages is fixed. That is to say, you create a DQMH module with a set of messages and you wrap the messaging API in a class and create an interface for that. Then you can have a ton of child classes that all accept the same set of messages. Your calling program just knows the interface, it doesn't care which actual DQMH module get's called behind the scenes.
One thing AF claims to do that it claims DQMH can't (at least not as easily)is the following: If you have a DQMH module with a specific set of messages say its an instrument driver. And you have an instrument that takes the same messages except it adds one feature (so another message). You want to have a module for the original and a module for the updated one. In AF your updated one just inherits from the original and you add one method and a message. that's it.
DQMH it's a little harder.You would have to use the original as a template and create a new updated one from the template and add the message. The difference is in AF, you have no duplication. You find a bug in one of the original functions you have to fix it one time in the AF approach. In the DQMH approach you would have to fix it in 2 places.
But that's only if you use a naive approach. You can encapsulate all the driver code in a class and throw it in the modules private data. Then you create the child class for the updated instrument. You still have to create another DQMH module. You still have some duplication, but it is only the messaging code. So yes not quite as elegant as AF, but for all intents and purposes same thing and much easier to debug.
You can choose the more elegant solution if you want, but what are you paying for it?
@WavePacket wrote:
@Darren wrote:
Another thing I'll add is that you don't want to over-engineer zero-coupling just for zero-coupling's sake. I've worked on lots of DQMH projects over the years, and modules will call each others' requests, and register for each others' broadcasts, and many times that's perfectly fine. You'll mainly be concerned about coupling if (1) you're writing a re-use module, or (2) you don't want "child" modules (for lack of a better term) sending requests to each other when it makes more sense to have higher-level modules be in charge of sending requests to children.
Yeah, I get that. I'm understanding this post to be that all the abstraction layers required for zero coupling frequently have cost (harder to understand, debug, test etc). Those considerations are valid, and might mean that choosing abstraction for the sake of it without articulating the necessity is a business mistake.
Here is everything you need to know about dependencies and coupling in DQMH. It's really easy to avoid circular dependencies and i don't find it requires any fancy engineering.
I don't think circular dependencies are the end of the world, but they are so easy to avoid, why would you have them?
Edit: I did not mean to mark this as the answer. I must have accidentally clicked on it. I have no idea how to undo that. if you do, let me know.
