@sorhu: w zasadzie cała ta klasa ma umożliwiać tylko synchroniczne przechowywanie i dostęp do pola bar przez kilka wątków, ale możesz napisać tak w skrócie, czemu to taka zła praktyka. A co do książki - zajrzę, dzięki.
@coll: No użyj Google, bo z telefonu pisać tyle mi się nie chce. A do przechowywania referencji pomiędzy wątkami masz AtomicReference. No i dlaczego singleton? Nijak nie jest to potrzebne do tego, co chcesz osiągnąć. Sprawdź, co oznacza S w SOLID.
@sorhu: To już trochę nadinterpretacja zasad SOLID. Idąc tym tokiem rozumowania, KAŻDA klasa łamie tę zasadę, gdyż każda posiada konstruktor.
Takie przesadne trzymanie się założeń SOLID prowadzi do powstawania strasznie wymyślnych mechanizmów, w których jedynie autor nie gubi się po tygodniu (ale po miesiącu już tak).
@fegwegw: To nie to samo. Co innego konstruktor, a co innego logika sterująca tworzeniem instancji. I to nie jedyny problem z singletonem. Innym jest mockowanie i testowanie go. Nie na darmo uważany jest za antipattern.
No oczywiście, zawsze jakieś zastosowanie się znajdzie, ale w znacznej większości przypadków singleton jest zupełnie zbędny.
Mam singleton, w nim jedno pole, getter i setter. Powiedzmy, że
class Foo {
private Foo foo = null;
private Bar bar;
public void setBar(bar nBar)
{this.bar = nBar;}
public Bar getBar(){return this.bar;}
public static Foo getInstance(){
if (foo == null) foo = new Foo();
return foo;}
private Foo(){};
}
Jak najlepiej uzyskać to, aby klasa była "thread safe"? Starczy dodać volatile do "foo" i synchronized do metod?
Komentarz usunięty przez autora
A jak chcesz koniecznie Thread safe, to poczytaj Effective Java. Jest tam o tym wspomniane.
No i użyj na przykład AtomicReference.
A do przechowywania referencji pomiędzy wątkami masz AtomicReference.
No i dlaczego singleton? Nijak nie jest to potrzebne do tego, co chcesz osiągnąć.
Sprawdź, co oznacza S w SOLID.
I zwracaj kopię Bar.
@sorhu: W jaki sposób łamiemy tutaj SRP, jeśli nie wiadomo nawet, co ta klasa robi?
1. Klasa przechowuje instancję czegośtam.
2. Klasa zajmuje się logiką tworzenia własnych instancji.
Taki sam problem jak z każdym innym singletonem.
Takie przesadne trzymanie się założeń SOLID prowadzi do powstawania strasznie wymyślnych mechanizmów, w których jedynie autor nie gubi się po tygodniu (ale po miesiącu już tak).
I to nie jedyny problem z singletonem. Innym jest mockowanie i testowanie go. Nie na darmo uważany jest za antipattern.
No oczywiście, zawsze jakieś zastosowanie się znajdzie, ale w znacznej większości przypadków singleton jest zupełnie zbędny.
ale ogólnie to lepiej wystrzegaj się singletona, bo zuo ( ͡° ͜ʖ ͡°)