Re: Design-Frage

Mike Wesling said...

Generell steckten in meinem OP zwei Fragen drin:

1) Wie gut ist der Stil, wenn ich Methoden habe, die ohne
Übergabe-/Rückgabeparameter sind und ihre Ergebnisse in eine
Klassenvariable schreiben?

Ein Objekt sollte IMO so wening Status wie möglich haben, das macht es
leichter es im Zweifel Threadsafe zu machen und macht es auc hleichter
etwas zu refactorn, sowie dem Programmverlauf zu folgen.

In diesem Sinne also nicht:

@NotThreadSafe
class Foo{

private Bar bar;

public void do(){
doPart1();
doPart2();
doSomethingElse();
}

private void prepareBar(){
bar = new Bar();
//...
}

private void useBar(){
if(bar != null && bar.equals(..)){
//..
bar.doSomething();
}
}
//...
}

Sondern:

@ThreadSafe
class Foo{

public void do(){
useBar();
doSomethingElse();
}

private Bar prepareBar(){
Bar bar = new Bar();
//...
return bar;
}

private void useBar(){
prepareBar().doSomething();
//...
}
}
//...
}


oder (IMO noch besser):

@ThreadSafe
class Foo{

public void do(){
useBar(preparedBar());
doSomethingElse();
}

private Bar preparedBar(){
bar = new Bar();
//...
return bar;
}

private void useBar(final Bar bar){
bar.doSomething();
//...
}
}
//...
}

oder gar:

@ThreadSafe
class Foo{

public void do(){
useBar(prepareBar(new Bar()));
doSomethingElse();
}

private Bar prepareBar(return Bar bar){
//...
return bar;
}

private void useBar(final Bar bar){
bar.doSomething();
//...
}
}
//...
}

Die Threadsafen-Varianten sind allesamt schneller, beim Multithreaded
Zugriff als wenn man die erste Variante mit synchronized-statements
threadsafe machen wollte.

Die einfachtse Regel für Threadsafety heißt: hat dein Objekt keinen
State (auch nicht durch benutzte, andere Objekte), dann ist es
Threadsafe.

2) Ist es überhaupt guter Stil, dass man alles, was man theoretisch an
Ort und Stelle in der Main ermitteln könnte, auf mehrere sehr kleine
Methoden aufteilt?

Ja. Man kann ja über Reflection sogar private Methoden per JUnit testen
und je weniger eine Methode macht, desto einfacher ist sie zu testen.
Und auch hier hast du mit Methoden, die keinen State erwarten einfach
weniger Mühe sie zu testen, vor allem, wenn die alle Paremeter bekommen,
statt sie sich holen zu müssen und ihre Ergebnisse entweder in einem
Parameterobjekt oder Rückgabeobjekt liefert, statt in eigenen
Attributen.

Zustand des Objektes ist gut gesagt. Wenn ich Klassen nur brauche, um
etwas zu erledigen, dann ist der konkrete Zustand eigentlich gar nicht
so von Bedeutung. Wenn ich aber als Aufrufer weiter mit dem
Klassen-Objekt arbeiten muss, dann sind die Daten bzw. der konkrete
Zustand schon wichtiger.

Die Kunst besteht darin, so weing Zustand wie irgend möglich zu halten
und die verschiedenen Zustandsvariablen zu unabhängig von einander wie
nur möglich zu bekommen, sodass möglichst viel parallel laufen kann.

Den geringere Masse an verbliebenen Zuständen kann man besser threadsafe
machen. Hier hat dann auch der Compiler mehr Möglichkeiten mit
lockElision, Escape-Analysis und ähnlichen Optimierungs-Taktiken die
Anzahl der gehaltenen Locks zu minimieren, bzw. hast du auch weniger
lock-contentions.

Gruß,
-Wanja-


--
Klingon function calls do not have 'parameters', they have 'arguments' -
and they always win them.
[Nele Abels in dsg]
.

Relevant Pages