Article View: pl.comp.objects
Article #14859Re: kolekcja/manager obiektów
From: Sektor van Skijlen
Date: Tue, 11 Jul 2006 14:36
Date: Tue, 11 Jul 2006 14:36
68 lines
4836 bytes
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-mailReferences:
<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