Wie wird der Anweisungsblock in einer Klasse genannt, der noch vor dem Konstruktor kommt (Java)?
Hier ein Beispiel:
public class A {
{
System.out.println("Initialisierung A");
}
public A() {
System.out.println("Konstruktorrumpf A");
}
}
Also hier der Block der vor public A() kommt, wie nennt man den und wann ist es sinnvoll, diesen zu verwenden?
lg Kath
2 Antworten
Ich kenne einen solchen Block nur mit dem Schlüsselwort "static" vorne dran. Das ist dann ein so genannter static block/static initializer. Dieser Block wird nur ein einziges Mal ausgeführt, wenn die Klasse geladen wird.
Konstruktoren werden hingegen jedes Mal ausgeführt, wenn eine neue Instanz der Klasse erzeugt wird (also mit new ein neues Objekt erzeugt wird).
Quelle: https://iq.opengenus.org/static-initialization-block-in-java/
Diese static-Blöcke sind in der Praxis ziemlich selten anzutreffen. In den meisten Fällen kann der Code problemlos im Konstruktor untergebracht werden, was ich empfehlen würde. Das ist (in meinen Augen) saubere Objektorientierung. Der static-Block ist für mich eine Art Fremdkörper, den ich lieber nicht benutze.
Ok, das gibt es tatsächlich und nennt sich "instance initialization block": https://www.tutorialspoint.com/non-static-blocks-in-java . Hab ich aber noch nie benutzt oder in freier Wildbahn gesehen.
Ja, ich würde diese Blöcke nach Möglichkeit nicht verwenden :D Gemeinsamer Code kann in eine Methode ausgelagert werden, die dann explizit in einem Konstruktor aufgerufen wird. Konstruktoren und diese komischen Blöcke parallel zu verwenden, finde ich verwirrend.
die sind aber chillig wenn du nicht vergessen willst in jedem konstruktor diese externe methode aufzurufen
klar haben initializer keine häufigen verwendungszwecke aber ich würde jz nicht unbedingt davon abraten
Erstaunlich, dass man dazu keine Feature-Bezeichnung findet
Es gibt ja noch den static Block, im Grunde also ein statischer Constructor/Initializer, der vor der ersten Nutzung der Klasse aufgerufen wird. Für mich sieht scheint das sowas ähnliches zu sein, nur eben nicht static, wie ein Instance-Initializer, der zuerst - auch vor den Konstruktoren aufgerufen wird.
Wirkt fast wie ein "zufälliges" Featurer, entstanden aus einem Bug, den man dann halt drin gelassen hat. Das würde auch erklären, warum es dazu so wenige Infos gibt.
Wann es nützlich ist, es zu benutzen:
Dann, wenn Du Initialisierungen hast, die überall gleich sind und vor den anderen Konstruktoren laufen sollen. Klar, man könnte auch einen parameterlosen Konstruktor definieren, aber so spart man sich Schreibarbeit und wenn der parameterlose Konstruktor nochmal etwas Anders machen soll, als alle anderen Konstruktoren, dann geht es nur so.
Ob es auch sinnvoll ist: Kommt vermutlich darauf an, wen Du fragst :D
Ich persönlich mag nicht, dass die ganze Definition fehlt, sieht irgendwie falsch aus.
Aber wenn ich (warum auch immer) wirklich so komplexe Konstruktoren habe, dass jeder "normal" definierte Konstruktor sich anders verhält, sie aber alle die gleiche Basis bekommen sollen, würde ich es nutzen.
Allerdings, wenn ich wirklich so komplexe Konstruktoren habe, schreit das mit einem Megaphone nach dem Factory-Pattern :D
Also nein, ich würde es vermutlich gar nicht nutzen.
Wirkt fast wie ein "zufälliges" Featurer, entstanden aus einem Bug,
Zum einen ist es eine eingehaltene Konsistenz. So, wie du in anderen Blöcken noch weitere Blöcke einfügen kannst,
class SomeClass {
void someMethod() {
{
{
}
}
}
}
ist das auch hier möglich. Zum anderen ist so ein Block in den Fällen nützlich, in denen man ein Objekt anlegen möchte, zu denen man keinen Konstruktor definieren kann, da der Typ anonym ist.
interface SomeInterface {
}
class SomeClass {
void someMethod() {
SomeInterface someObject = new SomeInterface() {
{
System.out.println("Hello world!");
}
};
}
}
In Java werden diese anonymen Code-Blöcke (initialization blocks) intern zusammgefügt und in die Konstruktoren kopiert, die keinen anderen Konstruktor aufrufen.
und was ist das dann in meinem Code für ein Block, wenn er nicht mit static beginnt?...