🚀 go-pugleaf

Przemek Pokrywka napisał(a):
> 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?

IMO jeżeli podsystem z singletonami jest "mały", to najlepiej przepisać 
jego fragmenty tak, by odpowiadały nowym wymaganiom bez kombinowania z 
kontekstami.

Jeżeli podsystem jest duży, to najlepiej zastanowić się nad jego 
założeniami, a potem przepisać jego fragmenty by odpowiadały nowym 
wymaganiom. Chyba, że jest to ostatnia zmiana w podsystemie - wtedy 
takie łatanie ma sens ekonomiczny.

Pozdrawiam


-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Przemek Pokrywka wrote:
> 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

Mam calkiem podobny problem, nad ktorym wlasnie glowkuje...

jezeli nie da sie zrefaktorowac do inline singletonu,
pozostaje kontekst, ale nie przekazywalbym tego przez konstruktory
- mamy jawnie przekazywany obiekt o ktorym klient w zasadzie nie 
powinien nic wiedziec - przy dluzszej "nitce" moze smierdziec ;)
Znacznie lepiej jest to ukryc za Factory ( ew. dodatkowo udekorowac 
obiekty )

ale wiadomo, wszystko zalezy od obecnej konstrukcji

ciekaw jestem dalszych postow

giku1 <giku@poczta.fm> writes:

[...]

> Mam calkiem podobny problem, nad ktorym wlasnie glowkuje...
>
> jezeli nie da sie zrefaktorowac do inline singletonu, pozostaje
> kontekst, ale nie przekazywalbym tego przez konstruktory - mamy
> jawnie przekazywany obiekt o ktorym klient w zasadzie nie powinien
> nic wiedziec - przy dluzszej "nitce" moze smierdziec ;) Znacznie
> lepiej jest to ukryc za Factory ( ew. dodatkowo udekorowac obiekty )

Dokładnie.  Najlepiej chyba zostawić ten singleton, tylko 
go 'podtypić' na kolekcję obiektów zawierającą metodę, która
pozwala wyłuskać z niej obiekt, którym obiekt korzystający 
z singletonu jest zainteresowany.  Parametrem metody może 
być właśnie ten kontekst.  Tak byłoby chyba najprościej 
i najbezpieczniej.

> ale wiadomo, wszystko zalezy od obecnej konstrukcji
>
> ciekaw jestem dalszych postow

No to masz :)

-- 
http://www.piotr.dembiński.prv.pl

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.

-- 
Filip Sielimowicz
http://panda.bg.univ.gda.pl/~sielim/fractal/index.htm

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

giku1 <giku@poczta.fm> writes:

[...]

> Rozwiazanie z watkami,

W podanym problemie nie było mowy o jakichkolwiek wątkach.  

Użytkownik "giku1" <giku@poczta.fm> napisał w wiadomości 
news:dqoa1i$m48$1@inews.gazeta.pl...

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

I tak właśnie jest. Przychodzi developer i jedną z pierwszych rzeczy,
których się dowiaduje jest: kochany, nigdy nie próbuj wywołać
funkcji logiki z wątku swinga, bo po pierwsze zwiesisz interfejs gui a po 
drugie system
w ogóle Cię nie wpuści, bo wątek swinga nie ma prawa nic grzebać z 
transakcjami
bd czy czymś w tym rodzaju. Czyli generalnie zapomnij w ogóle o tym, że
sobie pod buttonem w listenerze zrobisz cokolwiek ważnego. Od tego masz
akcje kontrolera, żeby się do nich podpinać.

> mozna pojsc jeszcze dalej, np. exception.printStackTrace( PrintStream 
> mojParser ) wyciagnac informacje skad jestem wolany.
> Niezla metoda zeby zrobic kumplowi kawal :).
Ostatnio w GW w Dilbercie było o tzw. policji analogicznej,
która aresztowała szefa Dilberta za to, że stosował niewłaściwe
analogie. 

Użytkownik "giku1" <giku@poczta.fm> napisał w wiadomości 
news:dqoa1i$m48$1@inews.gazeta.pl...
BTW. Jak mi na boku podpowiedział Piotr Kobzda, ideę wiązania kontekstu
z wątkami wspiera w javie klasa ThreadLocal:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ThreadLocal.html 

Zgodzilbym sie: w okreslonym i zdefiniowanym zakresie, a nie w globalnym 
nieograniczonym zakresie singletonu, prostytutki obiektowej :>, do 
ktorej kazdy ma dostep.

Filip Sielimowicz wrote:
> 
> Użytkownik "giku1" <giku@poczta.fm> napisał w wiadomości 
> news:dqoa1i$m48$1@inews.gazeta.pl...
> BTW. Jak mi na boku podpowiedział Piotr Kobzda, ideę wiązania kontekstu
> z wątkami wspiera w javie klasa ThreadLocal:
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ThreadLocal.html

Filip Sielimowicz wrote:
> 
> Użytkownik "giku1" <giku@poczta.fm> napisał w wiadomości 
> news:dqoa1i$m48$1@inews.gazeta.pl...
> 
>> 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 !
> 
> 
> I tak właśnie jest. Przychodzi developer i jedną z pierwszych rzeczy,
> których się dowiaduje jest: kochany, nigdy nie próbuj wywołać
> funkcji logiki z wątku swinga, bo po pierwsze zwiesisz interfejs gui a 
> po drugie system
> w ogóle Cię nie wpuści, bo wątek swinga nie ma prawa nic grzebać z 
> transakcjami
> bd czy czymś w tym rodzaju. Czyli generalnie zapomnij w ogóle o tym, że
> sobie pod buttonem w listenerze zrobisz cokolwiek ważnego. Od tego masz
> akcje kontrolera, żeby się do nich podpinać.
> 
>> mozna pojsc jeszcze dalej, np. exception.printStackTrace( PrintStream 
>> mojParser ) wyciagnac informacje skad jestem wolany.
>> Niezla metoda zeby zrobic kumplowi kawal :).
> 
> Ostatnio w GW w Dilbercie było o tzw. policji analogicznej,
> która aresztowała szefa Dilberta za to, że stosował niewłaściwe
> analogie.

btw. ten przyklad ze swinga to chyba tez nie za bardzo w temacie,
tak apropos policji analogicznej. Zadna funkcja nie zmieni zachowania
gdy zawolam ja z watku swinga.

giku1 <giku@poczta.fm> writes:

> Zgodzilbym sie: w okreslonym i zdefiniowanym zakresie, 
> a nie w globalnym nieograniczonym zakresie singletonu, 
> prostytutki obiektowej :>, do ktorej kazdy ma dostep.

W pajtonacz często zamiast singletonu lepiej jest użyć modułu.

Użytkownik "giku1" <giku@poczta.fm> napisał w wiadomości 
news:dqq48n$8vt$1@inews.gazeta.pl...

> btw. ten przyklad ze swinga to chyba tez nie za bardzo w temacie,
> tak apropos policji analogicznej. Zadna funkcja nie zmieni zachowania
> gdy zawolam ja z watku swinga.

Jeśli już mamy tak sobie swobodnie biegać machając słowami "zadna"
miast psich ogonków, to ja wolę zamachać po swojemu: "za to normalne
funkcje swinga stracą rezon".

I tak powstają legendy: że swing jest beznadziejnie wolny i w ogóle ...