🚀 go-pugleaf

"a1" <a1@no.spam> wrote:

>> Ale..
>> A po co obiekty maja miec referencje do managera ?
>> Nie mowie ze nie moga ale czy musza ?
> O ile manager nie jest singletonem to musza bo...

Nie musza.

>> Nie mozna tego zrealizowac inaczej czyli tak jak w zyciu ?
>> Przeciez gdy "odbijasz karte" po przyjsciu do pracy to wcale
>> nie musisz informowac o tym natychmiast managera.
>> Po prostu _zdarzylo sie_ ze odbiles.
> Ale odbija sie na czyms, czyli na zegarze, jezeli jest jeden zegar w 
> fabryce (manager jest singletonem) wiadomo gdzie isc zeby odbic, jezeli 
> jest ich wiele i kazdy pracownik ma przypisany swoj zegar to pracownik 
> musi pamietac do ktorego zegara ma isc (czyli obiekt musi trzymac 
> referencje na managera)

Zegar wcale nie musi miec cos wspolnego z managerem
(a juz tym bardziej zeby nim bez posrednio byl).
Zegar jest zaledwie jednym ze "zbieraczy zdarzen".

Slowem (bo juz mi sie nie chce ciagnac tego watku) do opisanej
przez Przemka sytuacji osobiscie najbardziej "pasuje" mi
"wzorzec rzeczywisty" czyli.

1. Sa sobie obiekty ktore generuja zdarzenia
2. Sa sobie "zbieracze zdarzen" jak wspomniany zegar
    panie w kadrach, itp. Mozna takiego zbieracza nazwac
   brzydko zarzadca zdarzen.
3. Sa sobie managerowie ktorzy sa zainteresowani
     informacjami o zdarzeniach generowanych przez obiekty.
     W tym celu rejestruja sie w "zbieraczach" na odpowiednia usluge
      (np daj dzienny raport przyjsc do pracy) o odpowiednich kryteriach
     (tu wchodzi cala sprawa uprawnien, autoryzacji itp pobocznych rzeczy).
     Jednym z kryteriow moze byc np to ze obiekt generujacy zdarzenie
      ma byc okreslonego typu i np przynalezec do grupu "Moj' :).

"Klasyczny" wzorzec Obeserver jest tylko obcieta wersja tego prostego
jak drut modelu zdarzeniowego. Wersja w ktorej "zbieracz zdarzen"
jest jednoczesnie managerem.
Tyle tylko czy w rzeczywistosci.. gdy przychodzisz do pracy
to odbijasz karte bezposrednio w paszczece kierownika ?

Ten ogolniejszy model oparty na "programowaniu zdarzeniowym"
ma  na pewno jedna niezaprzeczalna zalete.
Zupelnie oddziela swiaty (interfaces) obiektow od interface
managera/row.
Dziejej sie asynchronicznie.
W dodatku jest najblizszy rzeczywistosci "realnej" a nie
"IT technikalnej".

Wiem wiem.. jest problem muchy i armaty..
Na to jednak nie ma recepty poza dokladnym
rozpatrzeniem _konkretnego_ przypadku.
Tu nie wystarczy informacja "jest sobie manager i obiekty"
Tu trzeba wiedziec wiecej o tym co ta para realnie modeluje.

PS: tak tak... jestem zwolennikiem OO i "programowania zdarzeniowego".
        Sa chyba najblizej rzeczywistosci ze znanych mi "paradygmatow".
        Slowem (mowiac nowomowa IT): niech zyja kolejki zdarzen :)

PS1: Tak z ciekawosci: Jaki wzorzec/wzorce mozna przypasowac do w/w ?

EOT

AK