🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.objects
Article #14859

Re: kolekcja/manager obiektów

#14859
From: Sektor van Skijlen
Date: Tue, 11 Jul 2006 14:36
68 lines
4836 bytes
Dnia Tue, 11 Jul 2006 16:05:52 +0200, Adam Karpierz skrobie:
> "Darek Kubiczek" <darek_kubiczek@wp.pl> wrote in message

> > Hmm, wyglada na to ze chyba nie zrozumialem Przemka.
> > Mi chodzilo o wykorzystanie wzorca Observer nastepujaco: Manager
> > (obserwowany) i klienci Managera (obserwatorzy).
> > Podejscie w ktorym Manager obserwuje swoje obiekty-dzieci wydaje mi sie
> > dziwne.

> Dlaczego ?.
> Przeciez to jest jak najbardziej naturalne i rzeczywiste.
> Pracodawca (manager) obserwuje swoich p[racownikow mimo ze oni
> o tym nei musza (a nawet nei powinni) wiedziec.
> Pracownik ma jedynei obowiazek "notyfikowac" o tym co robi
> (odbic karte, wypelnic wnuiossek urlopowy itp).

Generalnie masz rację, ale po prostu nie na tym polega wzorzec Observer.

Rozważanie tego typu powinno przede wszystkim uwzględnić fakt istnienia stanów
(cząstkowych zresztą), ich zmienności i to właśnie te zmiany podlegają
obserwacji. Jeśli ktoś chce obserwować, to musi wiedzieć co i u kogo ma zamiar
obserwować. W przypadku wzorca Observer chodzi o zmienności, które mogą być
obserwowane przez dowolny obiekt, przy czym stany cząstkowe obiektu
obserwowanego cechuje duża zmienność i jest on wręcz takim "kontrolerem
zmian". Natomiast obiekty obserwujące obserwują tylko niektóre z tych zmian,
te, które je akurat interesują.

W tym, co przedstawiłeś, wygląda to zupełnie inaczej. Tam masz wiele obiektów,
które chciałbyś obserwować, wszystkie są do siebie podobne (tylko podobne!) i
ich zmienności są niemal identyczne. Poza tym obiekt nadzorczy nie musi na
bieżąco obserwować tego, co robi obiekt podległy - to nie ludzie, że trzeba im
ciągle patrzeć na ręce, czy pracują :). Obiekt nadzorujący jest zainteresowany
co najwyżej raportami z prac - a to robi się zupełnie inaczej: pracownik wie,
że ma wysłać raport do nadzorcy i wysyła go, gdy wykona przykazaną czynność,
względnie raportuje "progress", jeśli tak został zaprogramowany.

Generalnie różnica opiera się na tym, że w przypadku wzorca observer,
obserwowany obiekt nie tylko nie musi wiedzieć o tym, że jest obserwowany, ale
nie musi w ogóle wiedzieć, że istnieje obiekt obserwujący. Tak nie jest w
przypadku relacji manager-pracownik, bo nie bardzo sobie wyobrażam sytuację, w
której pracownik w ogóle nie wie, czy ma jakiegoś managera (patologie pomińmy
:).

> Manager to ktois kto chce meic informacje o tym czyms zarzadza
> czylki to wlasnei on obserwuje zmainy obiektow obserwowanych.
> Obiekty obserwowane nie powinny miec _zadnej_ informacji o tym
> czy ktos je  obserwuje czy nie i kto to jest itp.
> One jedynie powinny informowac (notyfikacje) o swoich zmianach.
> Informowac w ogole. Nie kogos konkretnego.

I tu tkwi właśnie błąd.

Po pierwsze, pracownik dostaje zlecenia wykonania zadań właśnie od managera i
jemu raportuje. Niewidzialność zatem jeśli nawet zostanie zorganizowana, jest
wyłącznie sztuczna. Po drugie, jeśli manager jest tylko obserwatorem, to w
takim razie jego pracę powinien móc obserwować każdy. Jeśli więc obserwację
połączysz z zarządzaniem, to możesz sobie wyobrazić, co się stanie, jeśli
takim obiektem będzie mógł również każdy zarządzać.

Relacja manager-klient powinna się zatem wiązać z wykonywaniem transakcji, a
nie rozgłaszania, które zakłada wzorzec observer.


-- 
//  _    ___         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"
Technical Details
Message-ID: <e90d12$f0q$1@kujawiak.man.lodz.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.man.lodz.pl!not-for-mail
References: <e8u9d9$bf1$1@news.onet.pl> <1152609582.735276.3000@s13g2000cwa.googlegroups.com> <e8vuu0$cnv$1@inews.gazeta.pl> <1152618395.489264.92060@35g2000cwc.googlegroups.com> <e90b83$89c$1@inews.gazeta.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.man.lodz.pl!not-for-mail
From: Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
Newsgroups: pl.comp.objects
Subject: Re: kolekcja/manager obiektów
Date: Tue, 11 Jul 2006 14:36:18 +0000 (UTC)
Organization: LODMAN - Metropolitan Area Network in LODZ, Poland
Lines: 68
Sender: Michal Malecki <sektor@zly.kis.p.lodz.pl>
Message-ID: <e90d12$f0q$1@kujawiak.man.lodz.pl>
References: <e8u9d9$bf1$1@news.onet.pl>   <1152609582.735276.3000@s13g2000cwa.googlegroups.com>   <e8vuu0$cnv$1@inews.gazeta.pl> <1152618395.489264.92060@35g2000cwc.googlegroups.com> <e90b83$89c$1@inews.gazeta.pl>
NNTP-Posting-Host: zly.kis.p.lodz.pl
Mime-Version: 1.0
X-Trace: kujawiak.man.lodz.pl 1152628578 15386 212.191.89.2 (11 Jul 2006 14:36:18 GMT)
X-Complaints-To: abuse@man.lodz.pl
NNTP-Posting-Date: Tue, 11 Jul 2006 14:36:18 +0000 (UTC)
User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (SunOS/5.9 (sun4u))
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit