🚀 go-pugleaf

> Na przykład tak:
> Monitor udostepnia metodę "ZarejestrujMnie", metoda przyjmuje jako 
> argument Delegate oraz jakiś identyfikator rodzajów zdarzeń, jakimi 
> subskrybent jest zainteresowany. Subskrybenci wołąją ZapiszMnie, 
> przekazując swój Delegate (swoją metodę obsługi zdarzenia). Dzięki temu 
> Monitor jest w stanie powiązać subsrybentów z oczekiwanymi typami zdarzeń.
> Gdy nadchodzi zdarzenie jakiegoś typu Monitor "przegląda" listę 
> subskrybentów i wynajduje tych którzy są zainteresowani danym typem 
> zdarzenia, a następnie wywołuje metodę przekazaną przez Delegate.
> Nie do końca eleganckie, bo nie izoluje zupełnie Monitora od Subskrybenta, 
> ale powinno spełnić Twoje oczekiwania.

też pomyślałem o czymś podobnym, tylko zastanawia mnie jaką przewagę ma to 
podejście od wysłania zdarzenia do wszystkich obiektów i niech one same 
decydują o tym czy są zainteresowane czy nie w zależności od parametrów 
zdarzenia.

w sensie projektowym różnica jest na niekorzyść tego pomysłu o którym mówisz 
w stosunku do tego wysyłania zdarzenia do wszystkich słuchaczy, właśnie z 
powodu braku izolacji.

możnaby to co prawda obejść projektując interfejs dla subskrybenta, 
przeglądania listy delegacji przypiętych do zdarznia przez 
GetInvocationList(), sprawdzaniu czy typ z którego pochodzi delegacja 
implementuje ten interfejs, a następnie odpytywanie się tego obiektu o to 
czy jest zainteresowany zdarzeniem, tyle że to niczego nie zmienia - i tak 
dla każdego subskrybenta trzeba wykonać kawałek funkcji, która sprawdzi czy 
jest on zainteresowany zdarzeniem czy nie. nie sądzę więc żeby była 
jakakolwiek różnica na korzyść w wydajności, możnaby to co najwyżej zbadać.

Wiktor Zychla