| 

.NET C# Java Javascript Exception

3
Wofür sind statische Blöcke zu gebrauchen? Hat jemand ein paar Verwendungsbeispiele? Bringen Sie welche Vorteile, z.B. bei der Performance? Nachteile?
News:
10.09.2009
ermin 1,3k 2 7
jor 781 2 7
6 Antworten
3
Ein Member einer Klasse kann für eine Instanz oder für den Typ implementiert sein. Allein aus dieser Betrachtungsweise ergeben sich schon die Unterschiede bzw. Einsatzszenarien.

Hauptsächlich sind statische Blöcke dazu gedacht Code in einer Klasse bereit zustellen der unabhängig von einer konkreten Instanz ist. Konkrete Verwendung zB bei einer Fabrikmethode:
class Foo
{
public static Foo Create()
{
return new Foo();
}
}

Weiters werden statische Blöcke für die Erstellung von Singletons benötigt und ganz essentiell als Einstiegspunkt einer jeden Anwendung (static void Main).

Der "Klassiker" für eine statische Klasse ist System.Math. Es würde keinen Sinn machen davon eine Instanz zu erstellen wenn nur die (statischen) Methoden ausgeführt werden.

Bezüglich Performance sind statische Methodenaufrufe marginal schneller denn der Compiler kann eine call-Anweisung generieren während bei Instanz-Methoden ein callvirt erstellt wird. Dies deshalb weil beim callvirt geprüft wird ob die Instanz nicht null - sonst könnte es krachen.

Nachteile: Wenn sie für das verwendet werden für was sie gedacht sind gibt es keine Nachteile.

Ich beziehe micht mit der Antwort rein auf C# ;)
10.09.2009
gfoidl 9,4k 3 5
Ich wollt doch schon sagen, dass hört sich aber nicht nach Java an :D aber dennoch wie immer eine treffende und richtige Antwort :)
Dustin Klein 10.09.2009
Naja - ich wuerde sagen: gfoidl hat die Frage falsch verstanden - es geht doch um statische Blöcke, nicht um statische Methoden - in der Antwort von fenchurch ist ein Beispiel.
cdaszenies 18.09.2009
Wenn ich das so betrachte hast du Recht wenn ein Block als Klasse definiert wird. Ich habs als Methode definiert (kann mit dem Begriff Block nicht anfangen).
gfoidl 18.09.2009
3
Ein static initializer block ist z.B. dann praktisch, wenn du eine statische Variable mit etwas initialisieren willst, was eine checked Exception wirft.

private static final File tmpFile = File.createTempFile("foo", ".tmp");


würde z.B. nicht kompilieren, da createTempFile() eine IOException wirft. Du kannst einen static initializer Block verwenden, um die Exception zu behandeln, also entweder in eine unchecked Exception umzuwandeln, oder die variable mit null zu belegen, oder was auch immer gerade sinnvoll ist:

private static final File tmpFile;

static {
try {
tmpFile = File.createTempFile("foo", ".tmp");
} catch (final IOException e) {
throw new RuntimeException(e);
}
}
11.09.2009
fenchurch 611 6
Im Beispiel wäre eine ExceptionInInitializerError angemessen, siehe deren Javadoc.
cdaszenies 18.09.2009
2
Hauptsächlich sind statische Blöcke dazu gedacht beim ersten Laden der Klasse ausgeführt zu werden. Im Gegensatz zu Konstruktoren sind sie nicht vererbbar. In diesem Beispiel wird foo beim Laden der Klasse auf 998877 gesetzt, sobald die Initialisierung vollständig ist:

public class test
{
static int foo = 12345;

static
{
foo = 998877;
}
}


Hierbei werden die statischen Initialiser so ausgeführt, wie sie der Reihenfolge nach im Code benutzt wurden. Hier gibt es jedoch auch einige Einschränkungen. So können in static blocks keine checked exceptions, kein return statement und keine this oder super keywords gebraucht werden.

Einige sind dabei der Meinung, dass das lediglich eine nervige Eigenart von Java ist, da Java keine first-class Klassen besitzt.

PS: Ich bin kein Java Anwender, von daher korrigiert mich bitte, wenn ich allzu falsch liege!
10.09.2009
Dustin Klein 2,9k 2 9
Der static Block einer Basisklasse wird auch beim Erzeugen einer Instanz einer Unterklasse aufgerufen, ähnlich wie der Default-Konstruktor, so er denn vorhanden ist und nicht durch super(x,y) ein andere Konstruktor angegeben wird. Static Blöcke kommen also auch in Unterklassen immer zum Einsatz, auch wenn sie nicht direkt vererbt werden. Konstruktoren werden im gleichen Sinne auch nicht wirklich vererbt.
jenser78 18.09.2009
0
static-Blöcke der Marke

class Foo {
{
// tu etwas Statisches
}
}

zerhacken den Kontrollfluss einer Anwendung. Ich sehe keinen Anwendungsfall, den man nicht auch ohne dieses Konstrukt lösen könnte. Mir würde ein bischen Augenmaß bei dem Einsatz dieser speziellen Konstrukte gefallen. Meine Empfehlung: Finger weg.
25.05.2011
oopexpert 455 1 8
-1
Nettes Beispiel: Date

Für Datumskonstanten muss man ja nun den Umweg über ein Calendar oder zumindest über ein paar (deprecated) Setter Aufrufe machen.

Man braucht also mehr als eine Zeile. Wenn man trotzdem den Vorteil von Konstanten haben will, (static final macht intern noch ein paar nette Dinge IIRC) muss man über diese Initializer-Blöcke gehen.

Man kann natürlich auch eine statische Fabrik bauen, dann *braucht* man sie nicht. Je nach Geschmack halt, aber gut sind sie dafür!
04.10.2009
deexem 109 2
-1
noch zwei Beispiele:
ähnlich wie bei fenchurch oder deexem zum Belegen einer static final Variable mit einem etwas komplexerem Objekt
private static final Map<String, String> DATA_MAP;
static {
Map<String, String> tmp = new HashMap<String, String>();
tmp.put("a", "1");
tmp.put("b", "2");
DATA_MAP = tmp;
}


zweites Beispiel ist JDBC. Beim Laden einer konkreten Driver-Klasse meldet sich diese in einem statischen Code-Block beim DriverManager an und ist danach verfügbar.
So z.B. bei HSQL:

static {
try {
DriverManager.registerDriver(new JDBCDriver());
} catch (Exception e) {
}
}

Das ist der Grund, warum man den Driver erst mit Class.forName() laden muss.
05.10.2009
micha_zeller 1 1

Stelle deine .net-Frage jetzt!