[coll]

#programowanie #java #naukaprogramowania

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?

[sorhu]

@coll: Mutowalny singleton? Masz Ty RiGCz?!

A jak chcesz koniecznie Thread safe, to poczytaj Effective Java. Jest tam o tym wspomniane.

No i użyj na przykład AtomicReference.

[coll]

@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.

[sorhu]

@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.

[fegwegw]

@coll: Wywal ten setter, będzie thread-safe.

I zwracaj kopię Bar.

[fegwegw]

Sprawdź, co oznacza S w SOLID.

@sorhu: W jaki sposób łamiemy tutaj SRP, jeśli nie wiadomo nawet, co ta klasa robi?

[sorhu]

@fegwegw:
1. Klasa przechowuje instancję czegośtam.
2. Klasa zajmuje się logiką tworzenia własnych instancji.

Taki sam problem jak z każdym innym singletonem.

[fegwegw]

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

[sorhu]

@fegwegw: Samo wywalenie settera nie sprawi, że to będzie thread safe. Just race condition na getInstance.

[fegwegw]

@sorhu: Masz rację.

[sorhu]

@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.

[kosmiczny_maupiak]

@coll: tu masz prawidziwy lazy thread-safe singleton bez żadnych double-check czy innego dziadostwa: https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom
ale ogólnie to lepiej wystrzegaj się singletona, bo zuo ( ͡° ͜ʖ ͡°)