I have a feeling there is a lot more to be said about this, and I think you maybe right and those architectures should be considered as anti-patterns. The biggest problem I find with event-driven stuff is how easy it is to lose track of what is happening, and how easy it is to introduce circular event triggering. I think the cleaner architecture would mean that it would be actually impossible to introduce a circular dependency. For example, it could be done similarly to the creation of objects. If you have classes:
It would be impossible to have a circular dependency such as above, because the creation of A's instance requires a B's instance, while the creation of B's instance requires an A's instance. So, you'll not be able to successfully run
leta=newA();// Error - need an instance of B as the 1st argumentletb=newB(a);
I think a similar way of thinking should be applied to events.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have a feeling there is a lot more to be said about this, and I think you maybe right and those architectures should be considered as anti-patterns. The biggest problem I find with event-driven stuff is how easy it is to lose track of what is happening, and how easy it is to introduce circular event triggering. I think the cleaner architecture would mean that it would be actually impossible to introduce a circular dependency. For example, it could be done similarly to the creation of objects. If you have classes:
It would be impossible to have a circular dependency such as above, because the creation of A's instance requires a B's instance, while the creation of B's instance requires an A's instance. So, you'll not be able to successfully run
I think a similar way of thinking should be applied to events.