🚀 go-pugleaf

Filip Sielimowicz wrote:
> U¿ytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisa³ w wiadomo¶ci
> news:dqjqn2$nv2$1@news.onet.pl...
> 
>>W tworzonym przeze mnie systemie u¿y³em w pewnej liczbie przypadków
>>wzorca singleton.
>>
>>W trakcie rozwoju projektu okaza³o siê, ¿e kilka z tych przypadków
>>powinno przestaæ byæ singletonami, a wej¶æ w sk³ad instancji pewnego
>>komponentu, który do tej pory by³ jeden w ca³ym procesie (systemu
>>operacyjnego), a wed³ug nowego wymagania powinna byæ mo¿liwo¶æ
>>posiadania jego kilku instancji.
>>
>>K³opot w tym, ¿e wiele kodu, maj±cego wej¶æ w sk³ad tego komponentu
>>polega ju¿ na globalnej obecno¶ci tych paru singletonów.
>>
>>W tej chwili narzuca mi siê rozwi±zanie, polegaj±ce na tym, ¿eby poprzez
>>konstruktory przekazywaæ te obiekty (najlepiej zgrupowane w jaki¶ obiekt
>>kontekstu) od obiektu komponentu do najmniejszego z obiektów sk³adowych
>>potrzebuj±cego korzystaæ z us³ug obecnych singletonów. Jest to jednak
>>dosyæ inwazyjna zmiana i ciekaw jestem, czy nie poradzi³ sobie kto¶
>>kiedy¶ z tym problemem w inny sposób?
>>
>>Przemek
> 
> 
> :)
> 
> Przyk³adem jest np. aplikacja, w której pierwotnie ma dzia³aæ jeden operator,
> z czasem okazuje siê, ¿e operator czasami musi siê prze³±czaæ, np. kto¶ musi
> autoryzowaæ operacjê wyp³aty du¿ej kwoty z kasy i ma zupe³nie inne uprawnienia
> (singleton managera uprawnieñ siada, bo my¶la³, ¿e ...), a potem jeszcze
> kto¶ wpada na pomys³, ¿eby logikê z aplikacji wynie¶æ na serwer aplikacyjny,
> gdzie równolegle pracuje 100 operatorów o ró¿nych uprawnieniach ...
> 
> I tego typu sprawy ...
> 
> Byæ mo¿e u Ciebie sprawa wygl±da podobnie, wiêc rozwi±zanie moze te¿ Ciê skusi.
> Otó¿ ka¿dy proces w systemie pracuje w kontek¶cie jakiego¶ w±tku i, przynajmniej
> w Javie, ma do tej informacji dostêp z ka¿dego miejsca w kodzie.
> W szczególno¶ci maj± do tej informacji dostêp metody getInstance() singletonów.
> 
> Wprowadzamy takie ograniczenie: pojêcie singletona zachowuje swoje znaczenie
> na poziomie w±tku, czyli w±tek zawsze widzi tylko jeden obiekt singletona
> i siê on nie zmienia. Natomiast implementacja metody getInstance() tam, gdzie
> singletony siê nam mno¿±, polega na tym, ¿e korzystaj± one z mapy obiektów,
> gdzie kluczem jest w±tek. W tym momencie na potrzeby ka¿dego w±tku mo¿emy
> zdefiniowaæ oddzielny obiekt singletona i jest to dla w±tku ca³kowicie
> przezroczyste. Ten, kto tworzy w±tek jest odpowiedzialny za to, by
> stworzyæ odpowiedni zestaw singletonów i powi±zaæ z w±tkiem.
> 
> Kluczem/wyznacznikiem kontekstu wcale nie musi byæ w±tek. Ale zazwyczaj
> w tego typu sytuacjach mo¿emy ³atwo znale¼æ w systemie jaki¶ punkt skupienia,
> wokó³ którego wszystko siê krêci, np. sesja zwi±zana z u¿ytkownikiem (a
> w±tki wtedy mog± byæ przydzielane dynamicznie do obs³ugi pojedynczych
> requestów). Wtedy metody getInstance singletonów jako klucz bior± sesjê,
> nie w±tek.
> 
> Mo¿na te¿ trochê od innej strony: scentralizowaæ zarz±dzanie singletonami
> i w jednej globalnej mapie trzymaæ obiekty trzymajace referencje na ca³y
> zestaw singletonów. Wtedy same singletony ju¿ nie trzymaj± w³asnych map,
> tylko odwo³uj± siê do jednej, gdzie ka¿dy ma swoje miejsce. Ale idea
> klucza reprezentuj±cego sta³y kontekst dalej ma tu zastosowanie.
> 

Rozwiazanie z watkami,

dziala niby piekne a jednak
uzaleznianie kontraktu funkcji od watku z ktorego jest wolana to jest 
czystej postaci HACK

refactoring to rape pattern ;)

przychodzi nowy developer,
ktorego trzeba poinformowac: uwazaj z ktorego watku to wolasz !

mozna pojsc jeszcze dalej, np. exception.printStackTrace( PrintStream 
mojParser ) wyciagnac informacje skad jestem wolany.
Niezla metoda zeby zrobic kumplowi kawal :).