Zpo-5-wyk-Slajd16: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
| Linia 1: | Linia 1: | ||
== | ==Singleton: implementacja z class loaderami== | ||
[[Image:zpo-5-wyk-Slajd16.PNG| | [[Image:zpo-5-wyk-Slajd16.PNG|Singleton: implementacja z class loaderami]] | ||
Inne rozwiązania wykorzystuje mechanizm działania tzw. class loader’ów wewnątrz maszyny wirtualnej. Obiekty class loader służą do ładowania klas i są zorganizowane w postaci drzewa. Każdy z nich, otrzymując żądanie załadowania klasy, aby uniknąć wielokrotnego załadowania tej samej klasy, zawsze najpierw konsultuje się ze swoim nadrzędnym class loaderem, czy nie załadował on już poszukiwanej klasy. W ten sposób poprawnie napisane class loadery (mogą one być definiowane przez programistę) zapewniają, że w maszynie wirtualnej zawsze znajduje się co najwyżej jedna reprezentacja danej klasy. | |||
Wzorzec może być wówczas zaimplementowany w postaci instancję klasy TaxA w statycznej klasie wewnętrznej Instance. Instancja ta jest tworzona w momencie załadowania klasy TaxA (oraz Instance) do maszyny wirtualnej, a sposób działania obiektu class loader zapewnia, że nie zostanie utworzona więcej niż jedna jej instancja. | |||
Rozwiązanie to działa poprawnie, o ile obiekty class loader zdefiniowane przez programistę zachowują się poprawnie, tj. konsultują ładowanie każdej klasy ze swoim nadrzędnym class loaderem. Jeżeli ta zasada zostanie naruszona, wówczas nadal istnieje niebezpieczeństwo utworzenia wielu instancji. | |||
[[zpo-5-wyk-Slajd15 | << Poprzedni slajd]] | [[zpo-5-wyk-toc|Spis treści ]] | [[zpo-5-wyk-Slajd17 | Następny slajd >>]] | [[zpo-5-wyk-Slajd15 | << Poprzedni slajd]] | [[zpo-5-wyk-toc|Spis treści ]] | [[zpo-5-wyk-Slajd17 | Następny slajd >>]] | ||
Aktualna wersja na dzień 11:03, 17 paź 2006
Singleton: implementacja z class loaderami
Inne rozwiązania wykorzystuje mechanizm działania tzw. class loader’ów wewnątrz maszyny wirtualnej. Obiekty class loader służą do ładowania klas i są zorganizowane w postaci drzewa. Każdy z nich, otrzymując żądanie załadowania klasy, aby uniknąć wielokrotnego załadowania tej samej klasy, zawsze najpierw konsultuje się ze swoim nadrzędnym class loaderem, czy nie załadował on już poszukiwanej klasy. W ten sposób poprawnie napisane class loadery (mogą one być definiowane przez programistę) zapewniają, że w maszynie wirtualnej zawsze znajduje się co najwyżej jedna reprezentacja danej klasy.
Wzorzec może być wówczas zaimplementowany w postaci instancję klasy TaxA w statycznej klasie wewnętrznej Instance. Instancja ta jest tworzona w momencie załadowania klasy TaxA (oraz Instance) do maszyny wirtualnej, a sposób działania obiektu class loader zapewnia, że nie zostanie utworzona więcej niż jedna jej instancja.
Rozwiązanie to działa poprawnie, o ile obiekty class loader zdefiniowane przez programistę zachowują się poprawnie, tj. konsultują ładowanie każdej klasy ze swoim nadrzędnym class loaderem. Jeżeli ta zasada zostanie naruszona, wówczas nadal istnieje niebezpieczeństwo utworzenia wielu instancji.
