The initial question is perfectly legit. And I can also understand and worked on this doing a personal message system.
There is not a basic publish\subscribe system through BP.
It should be something like
publish(senders) → broker(dispatchers) → subscribe (listeners).
It can be done with some workaround.
And yes there is an abuse of Interfaces that are used for something that they are not.
The interfaces should be interfaces that describe an Object(what should do). My opinion they are not the best solution to communicate making the code a mess if you are not able to organize the code very well. That is only My Personal opinion. A system as publish\subscribe could do the code very clear and simple for a lot of situations.
Very simple situation:
I have an inventory, I have 8 slots in the inventory. I click on the first slot. I just want inform all other slots that I have clicked on the first slot (so the slots can change the property themselves - example I want deactivate all slots not clicked).
I could do a “Get all widgets with class” or “Get all widgets with interface” and >>> CALL <<< a function\event\interface. But please note that from a code point of view it means:
- not so good for performance ( I Could have a a lot of widgets with that class or interface)
- I need to do a loop with the result returned (it is an array)
- I also need the node that call the function to deactivate the slots.
with a publish / subcribe system I resolve the situation in a simple and clean way:
on the click event of the slot I simply send a message to all subscribers to the topic “OnSlotClicked”.
All subscribers (the other slots) thare are in “listen mode” on that topic receive the event and can edit their proprierty deactivating themselves.
It is easy from every point of view:
- good performance
- very few nodes to use
- it really does what should does
Thanks.