🚀 go-pugleaf

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