🚀 go-pugleaf

Dnia Wed, 12 Jul 2006 18:59:46 +0200, Adam Karpierz skrobie:
> 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.

Adamie, im bardziej przystawiasz to do "rzeczywistego życia", tym bardziej
oddalasz się od "rzeczywistości oprogramowania".

Nie dlatego, żeby były między nimi aż takie różnice. To dlatego, że w jednym i
w drugim jest bardzo wiele szczegółów, którytch ty nie dostrzegasz. Twoja
wizja "rzeczywistości" jest mocno uproszczona, a niestosowalność danego
rozwiązania, które funkcjonuje w "rzeczywistości" w oprogramowaniu wynika z
jeszcze innej, prozaicznej przyczyny: czy próbowałeś sobie kiedyś wyobrazić,
jak wyglądałoby oprogramowanie, gdyby było pisane przez prawników?

> 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' :).

Super, pomysł jest dobry, co więcej, nawet stosowany, tyle że nie zawsze i
rzadko kiedy w funkcjonujących systemach. Wyobraź sobie np. gdybyś to
zastosował w systemie operacyjnym "dzienne raporty z usunięć plików". Ciekawe,
kiedy by ci nagle zaczęło na moment dziwnie brakować miejsca na dysku.
Zresztą, zróbmy to też tak, jak ty: wyobraź sobie, że straż pożarna ma usługę
"dzienny raport zgłoszeń pożarów". Albo pogotowie ratunkowe "dzienny raport
zgłoszeń zawału serca".

Oczywiście, że może istnieć jakiś "kontroler zdarzeń", tyle że to właśnie ten
kontroler zdarzeń staje się po części w pewnym sensie managerem: zbiera
zgłoszenia i zapamiętuje. Oczywiście, że może istnieć taki obiekt, a obiekt
faktycznego managera jest obiektem zupełnie oddzielnym i korzysta z
pośrednictwa kontrolera zdarzeń w pewnych sprawach - ale realizacja takiego
przedsięwzięcia musi być najpierw przeanalizowana pod kątem tego, czy to
rzeczywiście spełnia nasze wymagania odnośnie czasu dostarczenia raportu i czy
zdarzenie ma obsługę synchroniczną, oraz czy istnieje rzeczywiście taka
potrzeba, żeby istniał taki dodatkowy obiekt.

To co piszesz, nie jest całkiem bez sensu, jednak bezsensowna jest twoja
krytyka - to, co proponujesz podlega pod zupełnie inne wymagania systemowe i
jest takim "również dobrym rozwiązaniem", tyle że nie dla każdego przypadku.

> "Klasyczny" wzorzec Obeserver jest tylko obcieta wersja tego prostego
> jak drut modelu zdarzeniowego. Wersja w ktorej "zbieracz zdarzen"
> jest jednoczesnie managerem.

Totalna bzdura. Adamie, doczytaj może najpierw dokładniej, o co chodzi we
wzorcu Observer. Zauważ też, że Observer jest wąską specjalizacją
jednostronnej komunikacji, natomiast w żadnym wypadku nie jest modelem
współdziałania managera i pracowników. Nie ma to wręcz z tym nic wspólnego.

> 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.

Oraz jedną niezaprzeczalną wadę.

> Zupelnie oddziela swiaty (interfaces) obiektow od interface
> managera/row.

I co z tego? Ale łączy w sobie interfejs obustronny kontrolera zdarzeń oraz
interfejsy pracowników i managera. Też mi zaleta.

> Dziejej sie asynchronicznie.

Tak, szczególnie te "dzienne raporty" są synchroniczne.

> W dodatku jest najblizszy rzeczywistosci "realnej" a nie
> "IT technikalnej".

W uproszczeniu tak.

> Wiem wiem.. jest problem muchy i armaty..
> Na to jednak nie ma recepty poza dokladnym
> rozpatrzeniem _konkretnego_ przypadku.

Fajnie, gdybyś przed dyskutowaniem tego przykładu sam sobie to wziął do serca.

> 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".

A ja jestem zwolennikiem teorii stanów cząstkowych i technologii sygnałów i
slotów :).

>         Sa chyba najblizej rzeczywistosci ze znanych mi "paradygmatow".
>         Slowem (mowiac nowomowa IT): niech zyja kolejki zdarzen :)

Tak, szczególnie w obsługiwaniu zdarzeń synchronicznych.

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

Model-View Controller.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"