• 18/04/2007 16:54
• 

• Git! 0

  Kit! 0

prawda :) zapomniałem
wystarczy ze twoje połączenia będą musiały dziedziczyć po jakiejś klasie zawierającej już statyczną listę połączeń lub co gorsza jakaś klasa będzie dziedziczyła po twoich połączeniach. Wtedy qpa. wszystkie klasy w całym drzewie będą miały wspólna pulę połączeń. W razie błędu będzie ciężko dojść co i jak :) Po singletonie niemożna dziedziczyć więc połączenia nie będą "wyciekać" przez klasy potomne.
Wiem że można uczynić klasę final, ale chyba nie o to chodzi...

• 18/04/2007 17:26
• 

• Git! 0

  Kit! 0

> public ConnectionPoolSing getInstance(){

Zapomniales o jeszcze jednej waznej rzeczy: getInstance() musi byc statyczna.

> Z tego co wiem singleton ma tą przewagę nad klasą statyczną,
> że może dziedziczyć po jakiejś klasie lub implementować jakiś interfejs.
> [...]

Teoretycznie tak. Ale w praktyce, zeby dostac singletona i tak musimy odwolac sie do _statycznej_ metody getInstance(), tak ze cale to "programowanie do interfejsow" i "uniezaleznienie sie od implementacji" w tym momencie diabli biora.

• 18/04/2007 17:49
• 

• Git! 0

  Kit! 0

Ale dlaczego niby diabli biorą?

getInstance() zwraca obiekt tej klasy i tylko pilnuje by zwrócić zawsze ten sam. Jedyna różnica do nie-singletonu to statyczne getInstance() zamiast publicznego konstruktora. Nic nie tracimy z implementowania czy dziedziczenia.

InterfejsX x = KlasaImplementującaX.getInstan ce();

Równie dobrze (przynajmniej tak mi się zdaje) przy wielu różnych implementacjach możemy nie robić klas implemetujących singletonami tylko pilnowanie by stworzony i zwracany był tylko jeden obiekt danej klasy zlecić klasie fabrykującej.

• 18/04/2007 19:40
• 

• Git! 0

  Kit! 0

Jak czesto bedziemy wywolywali to getInstance()?

Zmierzam do tego, ze jesli w wielu miejscach, to znaczy, ze i tak mamy na sztywno zakodowana zaleznosc od KlasaImplementujacaX -- nie ma przewagi nad metodami statycznymi. Jesli zas tylko w niewielu miejscach (jednym miejscu?), to znaczy, ze w naszej aplikacji starannie kontrolujemy tworzenie obiektow KlasaImplementujacaX. A jesli kontrolujemy, to mozemy sami zadbac o to, zeby byl tylko jeden, bez narzucania niepotrzebnych ograniczen w samej implementacji tej klasy.

• 19/04/2007 09:06
• 

• Git! 0

  Kit! 0

a później przyjdzie jakiś nowy pracownik i już nie będziemy kontrolować co się dzieje z naszymi obiektami.

• 19/04/2007 09:08
• 

• Git! 0

  Kit! 0

>KosciaK napisał
>
>InterfejsX x = KlasaImplementującaX.getInstan ce();
>

a po co tak?
Nie łatwiej przez JavaBeans i metody ustawiające. Wtedy nawet nie trzeba rekompilować klasy :)

• 19/04/2007 10:35
• 

• Git! 0

  Kit! 0

>a później przyjdzie jakiś nowy pracownik i już nie
>będziemy kontrolować co się dzieje z naszymi obiektami.

Przyjdzie czy nie przyjdzie -- nieistotne. Mozliwe sa dwie sytuacje:

1. kontrolujemy tworzenie obiektow -> nie potrzebujemy wzorca singletona, bo mozemy (i powinnismy!) stworzyc jeden tylko obiekt w jednym miejscu kodu

2. nie kontrolujemy tworzenia obiektow (np. jak przyjdzie ten pracownik i cos rozgrzebie) -> mamy statyczne zaleznosci w kodzie -> singleton nic nam nie daje, mozna rownie dobrze uzyc metod statycznych.

• 19/04/2007 17:12
• 

• Git! 0

  Kit! 0

"1. Trudność singletona leży nie w jego implementacji, a w znalezieniu miejsca w którym można go wykorzystać. "

bzdura. mogę Ci znaleźć N+1 sytuacji, w których można wykorzystać singletona - przecież w zasadzie można wszystko pisać tylko singletonami (programowanie proceduralne z przestrzeniami nazw). Trudność polega na tym, żeby wiedzieć, w których z tych miejsc jednak nie należy z niego korzystać.

• 19/04/2007 18:11
• 

• Git! 0

  Kit! 0

>bartkiller napisał
>"1. Trudność singletona leży nie w jego implementacji, a
>w znalezieniu miejsca w którym można go wykorzystać. "
>
>bzdura. mogę Ci znaleźć N+1 sytuacji, w których można
>wykorzystać singletona - przecież w zasadzie można
>wszystko pisać tylko singletonami (programowanie
>proceduralne z przestrzeniami nazw). Trudność polega na
>tym, żeby wiedzieć, w których z tych miejsc jednak nie
>należy z niego korzystać.

OK. nie wyraziłem się dokładnie. w mojej wypowiedzi można = należy

• 22/04/2007 12:26
• 

• Git! 0

  Kit! 0

>bartkiller napisał
>"1. Trudność singletona leży nie w jego implementacji, a
>w znalezieniu miejsca w którym można go wykorzystać. "
>
>bzdura. mogę Ci znaleźć N+1 sytuacji, w których można
>wykorzystać singletona - przecież w zasadzie można
>wszystko pisać tylko singletonami (programowanie
>proceduralne z przestrzeniami nazw). Trudność polega na
>tym, żeby wiedzieć, w których z tych miejsc jednak nie
>należy z niego korzystać.

dodatowo dodam Bart, ze singleton jest dalej po to zeby ladnie sie kod synchronizowal miedzy stanami, i tylko po to, bo reszte mozna zrobic funckjami statycznymi, ale inicjalizacja musi byc zapewniona w kontekscie stanow, dlatego dobrze je uzywac tam gdzie mamy do czeynienia blisko ze input output, baza danych wlasnie.
a w praktyce mozna tez powiedziec ze singleton dalej latwo zmienic replacem na normalny obiekt :D
(co ja tak napieram dzisiaj o tych stanac???ble)

• 22/04/2007 16:50
• 

• Git! 0

  Kit! 0

>dodatowo dodam Bart, ze singleton jest dalej po to zeby
>ladnie sie kod synchronizowal miedzy stanami [...] ale
>inicjalizacja musi byc zapewniona w kontekscie stanow

A konkretnie? Jaki kod z jakim ma się synchronizować? Między jakimi stanami? Inicjalizacja czego? Poproszę na przykładzie z tą pulą połączeń.

Może masz na myśli coś bardzo mądrego, ale z tego postu niestety zupełnie to nie wynika.