Volgens mij draai je nu de contractverantwoordelijkheid om. Het idee dat Ralf stelt is dat de kern juist constant blijft en eventuele extra subscribers het zullen moeten doen met de door de kern gestelde contracten. Deze contracten zijn ook specifiek voor de in deze kern geautomatiseerde processen en zouden als zodanig geen uitbreidingen behoeven als er alleen een component wordt aangesloten.

Een andere situatie treedt op als de kern meer functionaliteiten gaat aanbieden, dan zal er wel uitbreiding plaats moeten vinden (maar nooit verandering van bestaande contracten).

ik moet zeggen dat ik het niet eens ben met je stelling dat in de laatste situatie (events) de kern niet complexer wordt ondanks het toevoegen van componenten.

Je zult namelijk bij elk event data moeten meegeven aan de component die het event afhandelt. Die data zullen aan een bepaald contract moeten voldoen. En dus verhoogt de complexiteit opnieuw lineair met het aantal componenten dat aangeroepen wordt of events afhandelt.

In het algemeen beschouw ik dependency injection als een pattern los van de context en IoC als een methode die component koppeling middels DI. Letterlijk betekend IoC natuurlijk iets anders, en daar valt de manier die ik hier beschrijf ook onder.

In dat geval is het observer pattern meer inversion of control dan dependency injection, dat immer alleen de tot stand koming van de koppeling voor zijn rekening neemt.

“Als we de richting van de koppeling omdraaien krijgen we een veel beter hanteerbare situatie.”

Ik denk dat je IoC en DI (Dependency Injection) niet mag verwarren.