Before I reinvent the wheel…
This is just an EXAMPLE for describing the problem — let’s say you have a backend with collection of some data, and frontend which displays one item of the collection.
At the backend I have ItemIndex — whenever it changes, it fires up OnScroll event.
I also have AddNewItem method, it adds new item at the end of the collection. The end of the method is calling OnNewItem event handler.
And here is the catch — in AddNewItem I have to change ItemIndex, which fires OnScroll. One of the receivers of both (!) OnScroll and OnNewItem if frontend which displays selected item.
In such case it is called twice (not good). One solution would be altering item_index instead of ItemIndex, and this way preventing OnScroll, but I don’t like it because ItemIndex does not act as black box anymore.
Is there any established pattern for sequential firing events, and sending only “important” ones (here: OnNewItem overrides OnScroll)? My idea would be to define an event scope, then instead of sending events directly, just register them for sending, and at the close of scope sort them and send the required ones.
In general — question — how should I deal with potential sequential event triggering. Use internals to avoid sending redundant events? Ignore the overhead? …?
The answer seems obvious to me athough I could have easily missed something:
One thing I would note is that you made mention of just simply altering item_index directly but that wouldn’t have a blackbox behavior. Well black box is all well and good … but that term only applies to objects interacting with this class we have been discussing.
You should feel empowered to use the internals of your class within itself. It is not good OOP to blackbox items within itself. If you are doing that then your class probably has design issues where it should be split into multiple classes.