Consider the following general program structure:
- Class A has an instance of Class B as a member variable
- Class B has a collection member variable containing instances of class C
- Events in class A are propagated to the C instances by A simply telling B about the event
What are the design patterns concerning instances of class C talking back to class A?
One option is instances of class C posting notifications to which class A subscribes. Another option is passing a reference to class A “down the chain” (from A to B then from B to each C). This latter option allows instances of C to talk directly to A.
If you mean design patterns literally (i.e. of the GoF variety) then these would be a few relevant options:
Citems (directly or indirectly through B) so that when they want to talk back toAthey can simply invoke this callback — which can even have parametersBexposes a view of its aggregate collection directly toA; communication betweenAandCis then made directlyAandCmight subscribe to; communication is done by posting eventsIf on the other hand you really mean architectural patterns, then typical options are:
Asubscribing toCevents. At first sight this doesn’t look like an all-around good idea unless the event is extremely useful all the time, because it requiresnobjects to aggregate a pointer back to the callback which in the worst case they could even use just once.Ais another option, but not a good one if you are going to pollute the public interface ofAwith methods just so thatCcan call back to it in very specific scenarios. It can be very effective ifAalready exposes a suitable interface, but be aware that you might need an adapter class betweenCcalling back toAin order to not tightly coupleCtoA‘s interface.Aiterating over (a view of) the collection provided byBdirectly and supplying callbacks toCinstances; this has the advantages of being quite loosely coupled and that it will use the least amount of memory, but it might be a bit trickier to code.