🚀 go-pugleaf

"Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
wrote:

>> A po co manager ma przekazywac jakis interface ?
>
> No, powiedzmy że manager musi być w jakiś sposób dostępny dla obiektów,
> którymi zarządza.

Nie powiedzmy.
_Kompletnie nie musi_.
Wlasciwie nie powinien.

>> Jednak masz zakorzenione spojrzenie na problem ze swiata
>> "patternomanii" gdzie zwykle  w opisywanych realizacjach Observera
>> obiekty wywoluja cos na managerze (rejestruja sie w nim itp).
>
> Jakim managerze??? We wzorcu Observera nie ma słowa o żadnym managerze.
> Jest obiekt obserwowany i obiekty obserwujące.

No tak.. Tutaj mamy kliniczny przyklad tego co napisal A.L.
<cytat>
W dyskusjach "patternowych" srodki
pzreslaniaja cel. Na ogol zapomina sie "po co i dlaczego" a patrzy
sie czy projekt ejst zgodny z podrecznikiem.
</cytat>

Wiesz jeszcze czego w ogole dotyczyli meritum czy juz masz w glowie
_tylko_ Observer.. Observer..

>> Rezczywistosc jest i inna i prostrza.
>> "Classic" Observer to nie zaden dogmat ! ;)
>
> Proponowałbym ci najpierw zapoznać się z wzorcem Observera.
> Linka podałem.

Po jaka cholere ?
Mam swoj "pattern" bardzo dobrze oddajacy rzeczywisctosc.
Po co mi cos jeszcze ?

>> Classic specjalnie w ciapkach bo co to mi za classic
>> w ktorym wiecej technikaliow niz odzwierciedlenia
>> "swiata rzeczywistego".
>
> Nie ma żadnych technikaliów we wzorcu Observera. Kwestia istnienia stanów,
> zachodzenia zdarzeń i obserwowania ich nie ma nic wspólnego z 
> technikaliami. A
> o niczym więcej wzorzec Observer nie mówi.

Mowi o rejestracji przez obiekty obserwatorow czy nie mowi ?

>> Dales koronny dowod tezy ktora podalem juz na poczatku.
>> Zwyciestwo "technikaliow" nad rzeczywistoscia.
>
> W tym sensie, to zwycięstwo technikaliów nad rzeczywistością
> będzie miało miejsce bardzo często :)

Kompletna bzdura.
Zmiana modelu tylko po to aby uzyskac "wydajnosc"
zamiast uzyskania "wydajnosci" droga optymalizacji i szukania
bottle neck-ow istneijacego _prawidlowego_ modelu jest typowym
przykladem zlego podejscia do projektowania/programowania
_w ogole_.

>
>> > Przetwarzalismy duza liczbe stosunkowo malych obiektow.
>> > Koszt 'referencji do managera' (a zwykle do managerow)
>> > byl dla nas znaczacy.
>
>> Ale..
>> A po co obiekty maja miec referencje do managera ?
>> Nie mowie ze nie moga ale czy musza ?
>
> To wszystko zależy, właśnie od modelu hierarchii.
> W szczególności o przepływie
> informacji. Jeśli interesuje nas przepływ informacji tylko w jedną stronę,
> czyli taki model "despotyczny" ("Góra mówi, dół słucha" - skąd to 
> znamy?:), to
> wtedy obiekty nie muszą mieć referencji do managera. Jeśli jednak istnieje
> jakikolwiek przepływ informacji również w drugą stronę (a często 
> istnieje), to
> bez referencji do managera się nie obejdzie.

Nie rozsmieszaj mnie.
Obejdzie sie i to w sposob lepszy.

>> Przeciez gdy "odbijasz karte" po przyjsciu do pracy to wcale
>> nie musisz informowac o tym natychmiast managera.
>
> Oczywiście, ale ty mówisz o sytuacji, gdy pracownik nawet w ogóle nie 
> odbija
> karty.

A skad ci cus takeigo przyszlo do glowy ?

>> Po prostu _zdarzylo sie_ ze odbiles.
>
> Czekaj, czekaj.
>
> Mówisz teraz o idei, czy o technikaliach?

Mowie o zyciu.
Nie zauwazyles ze w zyciu wystepuja najnormalniejsze wv swiecie
zdarzenia ?

> Jedną z form realizacji Observera

No i ten dalej swoje. .. Observer i Observer :)

> Natomiast ideologicznie, oczywiście, żaden obiekt nic nie wie o drugim.
> Rzeczywiście, obiekt nadajnika i odbiornika posiadają odpowiednio sygnał i
> slot, ale jawnie żadnych referencji do obiektów nie posiadają.
> Tylko co to ma do rzeczy?
> Fizycznie te referencje istnieją, tyle że są ukryte w obiekcie sygnału.

I co ? I Ty nie widzisz roznicy ?
Roznica jest _zasadnicza_.

AK