JAVA: wozu static?

[Gast]

abend,

bin gerade dabei mich in die oop anhand von java einzuarbeiten. bin nun auf das wörtchen static gestoßen und hab damit so meine probleme.
ich weiß, dass static klassenvariablen / -methoden erzeugt und diese können quasi nur untereinander agieren. doch ich weiß nicht, welchen sinn das hat.

wann soll ich selbst meine methoden und variablen auf static setzen und wann nicht? welchen vorteil hab ich, wenn methoden/variablen static sind?

danke schonmal für die hilfe!

[Der_Donnervogel]

Der große Unterschied zu den normalen Methoden (und Variablen) liegt darin, dass static-Methoden unabhängig von einem Objekt sind. Das bedeutet man muss nicht erst eine Instanz erzeugen um diese Methoden benutzen zu können. Gleichzeitig bedeutet es aber auch, dass alle Objekte die selben benutzen. Das ist vor allem bei static Variablen ein sehr wichtiger Unterschied, da es bedeutet, wenn ein Objekt so eine Variable ändert hat sie auch für alle anderen Objekte den neuen Wert. Static Methoden können auch mit Methoden und Variablen von Objekten interagieren. Sie müssen allerdings zu einem Objekt gehören. Das bedeutet man muss sie qualifizieren. Es genügt also nicht z.B. hallo() aufzurufen, sondern man muss objekt.hallo() aufrufen. Man befindet sich ja in einer static Methode nicht im Kontext eines Objektes, sondern im Kontext der Klasse. Folglich wüsste Java nicht die hallo() Funktion welches Objektes aufgerufen werden soll. Das geht nur wenn sie qualifiziert wird. Wenn man sich in einem Objekt befindet wird immer automatisch ein this ergänzt, weswegen man sich das qualifizieren des aktuellen Objekts sparen kann. Ein this.hallo() ist deshalb überflüssig, wenn auch möglich. Umgekehrt wiederum kann man jederzeit auf static-Methoden, sowohl aus einem Objekt als auch von einer static-Methode aus zugreifen.

Sehr oft benötigt man static aber nicht. Die allermeisten Methoden und Variablen werden nicht static sein. Es gibt aber schon Einsatzmöglichkeiten. Wo es z.B. Verwendung findet ist beim Factory Pattern. (http://de.wikipedia.org/wiki/Factory_Pattern)

Am besten vielleicht auch einfach mal etwas in der Klassenbibliothek von Java stöbern. Dort gibt es einige Beispiele wo und wie static-Methoden verwendet werden können. Ein Beispiel wären die diversen valueOf-Methoden der String Klasse, oder auch Dinge wie getInteger der Integer Klasse, usw.

[Tesseract]

im grunde ist es ganz einfach:

wenn du eine klasse schreibst, schreibst du eigentlich ein objekt von dem jedes mal, wenn du den constructor aufrufst eine kopie angelegt wird. wenn du irgendwas static machst, wird es nicht mit kopiert sondern existiert nur in dem grundobjekt, von dem alle anderen objekte kopiert werden.
dementsprechend kann man es natürlich auch so interpretieren, als hätten alle instanzobjekte der klasse gemeinsame variablen. in wahrheit nutzen aber alle die variable des grundobjekts.

[Coda]

Was für ein "Grundobject"? Steht das so in der Java-Doku?

Vor allem wird nichts kopiert. Es gibt pro static-Element genau eine Variable im Speicher.

[Gast]

also schonmal danke für die hilfe, jetz seh ich wenigstens einen sinn hinter static.^^
hab ich das also richtig verstanden:

static methoden müssen immer über den klassennamen aufgerufen werden, da sie ja nicht direkt mit einem object arbeiten. also zb:
Out.println();
und non-static methoden müssen immer auf dem erzeugten objekt aufgerufen werden also zb:
auto.kaufen();
?

was ich allerdings noch nicht verstanden habe:
in meinem schlauen buch steht, dass klassenmethoden direkt nur mit klassenvariablen arbeiten. wieso kann ich dann zb in der static main methode ein objekt erzeugen und dann mit den instanzvariablen arbeiten?

[Novox]

wenn du eine klasse schreibst, schreibst du eigentlich ein objekt von dem jedes mal, wenn du den constructor aufrufst eine kopie angelegt wird.

Wirklich? Das hab ich nämlich in Bezug auf Java noch nie gehört. Das was Du da erzählst, klingt doch eher nach einem Prototyp-basiertem OO-Modell wie es z.B. JavaScript implementiert.

[Monger]

Vielleicht erstmal als Hintergrund - was bei vielen Leuten zu Verständnisproblemen führt:

In objektorientierten Sprachen ist ALLES ein Objekt. Selbst Klassen sind Objekte. Das heißt: nicht nur das Haus ist ein Objekt, sondern auch der Bauplan für das Haus ist ein Objekt. Und auch der Bauplan kann Eigenschaften und Verhaltensweisen besitzen.
In Java ist das halt beides miteinander in der selben Datei vermischt.

Klassen Objekte können (normalerweise) nicht vom Programmierer instanziiert werden, sondern nur von der Java Runtime. Die macht das einmalig, sobald die Klasse das erste mal irgendwo namentlich im Code erwähnt wird. Wenn du also ein Java Programm startest, schaut die Runtime erstmal ins Manifest, und sieht dort erstmal einen Klassennamen. Diese lädt sie dann , und sucht anschließend darin nach der Main Methode, und führt diese aus. In der Main Methode werden dann (normalerweise ;) ) andere Klassennamen erwähnt, die dann die Runtime Stück für Stück nachlädt.

Die Runtime lädt die Klassen Objekte bei der ersten Verwendung, und entlädt sie erst wieder mit Programmende - deshalb sind Klassen inklusive ihrer Methoden und Attribute ("static") vom gesamten Programm aus zugänglich.

Statische Attribute werden - wie jedes andere Objekt auch - zum Konstruktionszeitpunkt initialisiert. Es gibt sogar statische Konstruktoren!

Public Class MyClass{
public static MyString;
static{ // statischer Konstruktor!!
MyString = "xyz";
}
}

Wir haben hier also zwei Sorten von Objekten. Klassen sind grundsätzlich in der Runtime jederzeit bekannt, deshalb dürfen die beliebig referenziert werden. Aber eine Klasse darf auch Objekte referenzieren, sofern sie sie kennt. In meinem Codebeispiel wird ja auch eine Instanz vom Typ String erzeugt, und in der Klasse statisch unter "MyString" abgelegt.

[Tesseract]

Vor allem wird nichts kopiert. Es gibt pro static-Element genau eine Variable im Speicher.
hab ich ja geschrieben.

Wirklich? Das hab ich nämlich in Bezug auf Java noch nie gehört. Das was Du da erzählst, klingt doch eher nach einem Prototyp-basiertem OO-Modell wie es z.B. JavaScript implementiert.
wenn ich mich richtig erinnere hat mir das mal jemand so erklärt, der selbst an einem java compiler mitgearbeitet hat.
und bei einer "richtigen" prototypbasierten sprache hat man doch wesentllich mehr kontrolle über das klassenobjekt. bei java ist das alles eine compilezeit-geschichte.

[Abnaxos]

In objektorientierten Sprachen ist ALLES ein Objekt. Selbst Klassen sind Objekte. Das heißt: nicht nur das Haus ist ein Objekt, sondern auch der Bauplan für das Haus ist ein Objekt. Und auch der Bauplan kann Eigenschaften und Verhaltensweisen besitzen.
Ich denke, der Vereinfachung halber kann man das so stehen lassen. Tatsächlich allerdings unterscheidet Java klar zwischen Klassen und Objekten. Via Reflection gibt es zwar auch Objekte, die Klassen repräsentieren, das ist aber eben nur ein Abbild, eine Ansammlung von Meta-Daten, nicht ein Klassenobjekt, wie es z.B. Smalltalk kennt.

Aber wie gesagt, der Vereinfachung halber kann man das ignorieren und die Klasse selber als Objekt betrachten.

wenn ich mich richtig erinnere hat mir das mal jemand so erklärt, der selbst an einem java compiler mitgearbeitet hat.
und bei einer "richtigen" prototypbasierten sprache hat man doch wesentllich mehr kontrolle über das klassenobjekt. bei java ist das alles eine compilezeit-geschichte.
Ähm … also den Compiler möchte ich dann lieber nicht verwenden. ;) Sorry, aber das ist schlicht falsch. In Java wird ein Objekt alloziiert, dann wird der Initialisierer, danach der Konstruktor ausgeführt. Zu keinem Zeitpunkt wird da ein Objekt kopiert.

[Gast]

static methoden müssen immer über den klassennamen aufgerufen werden, da sie ja nicht direkt mit einem object arbeiten. also zb:
Out.println();

println() ist nicht statisch und "out" wird kleingeschrieben und ist keine Klasse. System.out.println() lautet der Befehl.

[stav0815]

Vor allem wird nichts kopiert. Es gibt pro static-Element genau eine Variable im Speicher.
Was ja auch genau der Knackpunkt sein sollte, alles andere wäre sinnfrei.

[patermatrix]

wann soll ich selbst meine methoden und variablen auf static setzen und wann nicht? welchen vorteil hab ich, wenn methoden/variablen static sind?
Ein oft genanntes Beispiel für statische Variablen ist z.B. die Vergabe von eindeutigen IDs.

public class MyClass{
private static int counter = 0; // wird nur beim erstmaligen Instanzieren eines Objekts aufgerufen
private int id;

public MyClass(){
id = counter++;
}
}

So erhalten alle erstellten Instanzen der Klasse eine eindeutige, aufsteigend nummerierte ID.

Gute Beispiele für statische Methoden wurden ja schon genannt, auch die java.lang.Math Klasse bietet weitere anschauliche Verwendungen. Es wäre eher mühsam, für Standard-Funktionen wie sqrt() oder abs() jedes Mal ein java.lang.Math Objekt erzeugen zu müssen.

Weiss eigentlich zufällig jemand, wieso das bei java.util.Random nicht auch so gelöst wurde? Weil da jedes Mal ein neuer Seed verwendet wird?

€: Sehe gerade, dass es dafür ja Math.random() gibt...

[Shink]

Na sowas - 12 Posts zum Thema "static in Java" und keiner sagt dass es eigentlich böse ist.

Also nun von mir: Woimmer es geht sollte man das Zeug nicht statisch machen denn was erst einmal statisch ist lässt sich nicht mehr austauschen.
Prinzipiell benötigt man es nicht (außer vielleicht bei "static void main()").

Heutzutage macht man das üblicherweise mit Dependency Injection.
Es wäre eher mühsam, für Standard-Funktionen wie sqrt() oder abs() jedes Mal ein java.lang.Math Objekt erzeugen zu müssen.
Das würde man z.B. ersetzen durch:
- Meine Klasse hat eine Referenz auf eine Math-Instanz.
- Diese wird automagisch über meinen IOC-Container gesetzt.

[Tesseract]

Ähm … also den Compiler möchte ich dann lieber nicht verwenden. ;) Sorry, aber das ist schlicht falsch. In Java wird ein Objekt alloziiert, dann wird der Initialisierer, danach der Konstruktor ausgeführt. Zu keinem Zeitpunkt wird da ein Objekt kopiert.

und was macht der "initialisierer"?

[Gast]

Na sowas - 12 Posts zum Thema "static in Java" und keiner sagt dass es eigentlich böse ist.


Welche genau Erklärung hast du hierfür, ausser mal etwas gesagt zu haben?


Heutzutage macht man das üblicherweise mit Dependency Injection.


Ne ist klar, du hast ja auch immer Spring oder ein ein ähnliches Rahmenwerk zur Hand. Und selbst wenn, würde ich trotzdem nicht alles mit Dependency Injection machen. Wolltest wieder mal nur was sagen, ohne genaue Kenntnis der Gesamtsituation, oder?

"automagisch"

Sehr lustig, wirklich.

Wenn du dich nicht komplett lächerlich machen willst, dann gib hier doch bitte eine genaue fundierte Erklärung ab und nicht etwas was so klingt, als hättest du mal irgendwo was gehört.

[Abnaxos]

und was macht der "initialisierer"?
Ist ähnlich wie der Konstruktor, wird aber vorher ausgeführt. Der «statische Konstruktor», den Monger erwähnt hat, ist eigentlich kein statischer Konstruktor, sondern eben ein statischer Initialisierer (klingt doof auf deutsch, «static initialiser» halt).

Dort hinein wandert z.B. das Initialisieren der Felder, wenn der Anfangswert bei der Deklaration des Felds angegeben wurde.

public class Test {
private int answer = 42;

{
System.out.println("The answer is "+answer);
}

public Test() {
System.out.println("This is the constructor");
}
}

Die Ähnlichkeit zu Mongers Beispiel in der Syntax ist offensichtlich: «static {...}» ohne «static». Das ist aber ein Detail und wird eigentlich nie verwendet. Wenn man sich den Bytecode ansieht, dann sieht man, dass dieser Code implizit nach dem Aufruf des Super-Konstruktors und vor dem eigenen Konstruktor-Code in jeden Konstruktor eingefügt wird.

Compiled from "Test.java"
public class Test extends java.lang.Object{
public Test();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: aload_0
5: bipush 42
7: putfield #2; //Field answer:I
10: getstatic #3; //Field java/lang/System.out:Ljava/io/PrintStream;
13: new #4; //class java/lang/StringBuilder
16: dup
17: invokespecial #5; //Method java/lang/StringBuilder."<init>":()V
20: ldc #6; //String The answer is
22: invokevirtual #7; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
25: aload_0
26: getfield #2; //Field answer:I
29: invokevirtual #8; //Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
32: invokevirtual #9; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
35: invokevirtual #10; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
38: getstatic #3; //Field java/lang/System.out:Ljava/io/PrintStream;
41: ldc #11; //String This is the constructor
43: invokevirtual #10; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
46: return

}

}

0-1: super()
4-7: int answer=42
10-35: System.out.println("The answer is "+answer)
38-43: System.out.println("This is the constructor")


Edit: In dem Bytecode sieht man auch schön die zwei Schritte anhand des StringBuffer: Zuerst allozieren (13: new #4), dann initialisieren (17: invokespecial #5). Ähnlich wie in Objective-C: [[MyClass alloc] init] (als Abkürzung geht meist auch [MyClass new], das gilt aber als schlechter Stil).

[Shink]

Wenn du dich nicht komplett lächerlich machen willst, dann gib hier doch bitte eine genaue fundierte Erklärung ab und nicht etwas was so klingt, als hättest du mal irgendwo was gehört.
- vielleicht will ich mich ja lächerlich machen:freak:
- wie willst du z.B. etwas das static ist im Test mocken?
- statische Methoden lassen sich nicht unglaublich toll in einem Interface-basierten Design verwenden
- DI ist älter als die Frameworks dafür. Nichts hindert einen daran die Abhängigkeiten über eine Factory zu injizieren.
- prinzipiell hat man mit statischen Methoden und Fields ein Singleton (nämlich das Class-Objekt). Und Singletons gelten i.A. als böse.

Wegen der vielen Nachteile wird das Singleton-Muster (und auch das Idiom Double-checked Locking) mitunter schon als Anti-Pattern bewertet. Für Fälle, wo tatsächlich technisch ein passender Bereich für ein Singleton existiert, können Singletons aber sinnvoll sein – insbesondere wenn sie sich auf andere „einmalige Strukturen“ wie zum Beispiel eine Abstract Factory beziehen. Trotzdem: Das korrekte Design von Singletons ist schwierig – in der Regel schwieriger als Designs ohne Singletons.
http://de.wikipedia.org/wiki/Singleton_(Entwurfsmuster)#Nachteile
http://steve.yegge.googlepages.com/singleton-considered-stupid

Mir ist klar dass static und Singletons Sinn machen können aber meistens sollte man sie vermeiden. Es nimmt sie aber jeder her; gerade die die sich kaum Gedanken zum Design oder der Wiederverwendbarkeit machen.
Deswegen find ich eine Warnung in einem Thread "Wozu static" schon notwendig.

[Dr.Doom]

static und singlton sind nicht pauschal böse. Wenn man weiss, was man vorhat, dann ist deren Anwendung vollkommen in Ordnung.
Nicht selten ist die nötige Happelei, nur um keinesfalls etwas, das als "böse" gilt, zu vermeiden, uneffektiver.
Genauso wie Vererbung hinsichtlich Erweiterbarkeit das Potential hat, auch "böse" zu sein, so ist Vererbung pauschal halt eben nicht "böse"... :freak:

[Shink]

Nicht selten ist die nötige Happelei, nur um keinesfalls etwas, das als "böse" gilt, zu vermeiden, uneffektiver.
Hmm... keinesfalls etwas vermeiden dass als böse gilt ist ineffektiv?
:uconf2:

[Monger]

Ich empfinde statische Methoden auch eher als "Anomalie": Sie kennen keine richtige Vererbung, kein Überladen, keine Interfaces... auch Debugging ist im Typ Initialisierer hässlich. Multithreading geht damit auch nicht, statische Klassen durchbrechen das Konzept der Kapselung (global verfügbar), und damit ist auch Refactoring erschwert.

Die Annahme, dass etwas global nur einmalig existiert, ist sowieso fragwürdig. Das sollte dem Anwender bzw. dem aufrufenden Code überlassen sein. Wer statische Attribute als Konstanten-Pattern mißbraucht, gehört sowieso gehauen.

Aber: es gibt halt auch einiges, was sich nur mit Instanzen alleine nicht lösen lässt. Das Factory Pattern z.B. ist irrsinnig praktisch. Aber insgesamt stimme ich Shink schon zu: mit static sollte man sehr sparsam umgehen.

[Dr.Doom]

Hmm... keinesfalls etwas vermeiden dass als böse gilt ist ineffektiv?
:uconf2:
Na, stell dich mal nicht so an.
Da ist halt ein Wort zuviel, weil's beim Überarbeiten eines Satzes übriggeblieben ist. Du findest schon raus, welches Wort das ist, und was meine beabsichtigte Aussage ist.

[Shink]

Vielleicht wars ja ironisch gemeint.

Um jeden Preis gewisse Dinge zu vermeiden find ich jedenfalls einfacher als die Vorgabe "alles ist erlaubt aber im Endeffekt muss alles sauber sein".

[Abnaxos]

Ich gehöre ganz klar zur Fraktion, die das Singleton-Pattern als Anti-Pattern bezeichnet. Ich arbeite wenn immer möglich/sinnvoll mit IoC/DI. Zu oft ist es mir passiert, dass ich fand: «Oh, von dem Ding gibt es nur eines, ich mache einen Singleton» und später brauchte ich plötzlich doch mehr von den Dingern. Das hat jedes Mal wieder einen riesen Spass gemacht, das aufzudröseln.

[Coda]

hab ich ja geschrieben.
Mich wundert dein "Grundobjekt". Und das "In Wahrheit nutzen". Kommt mir komisch vor.

[Gast]

Ich gehöre ganz klar zur Fraktion, die das Singleton-Pattern als Anti-Pattern bezeichnet. Ich arbeite wenn immer möglich/sinnvoll mit IoC/DI. Zu oft ist es mir passiert, dass ich fand: «Oh, von dem Ding gibt es nur eines, ich mache einen Singleton» und später brauchte ich plötzlich doch mehr von den Dingern. Das hat jedes Mal wieder einen riesen Spass gemacht, das aufzudröseln.

Interessant, etwas wird zum Anti-Pattern deklariert, weil man nicht selbst in der Lage war vorab zu erkennen, wann etwas unabdingabar ein Singleton sein muss und wann nicht. Nur zur Info: Man muss nicht immer alles verwenden, nur weil man mal davon gehört hat. Die Regel sollte sein, nur dann etwas zu verwenden, wenn man es auch verstanden hat.


Mir ist klar dass static und Singletons Sinn machen können aber meistens sollte man sie vermeiden. Es nimmt sie aber jeder her; gerade die die sich kaum Gedanken zum Design oder der Wiederverwendbarkeit machen.
Deswegen find ich eine Warnung in einem Thread "Wozu static" schon notwendig.

Abnaxos ist offenbar ein Programmierer dieser Kategorie. Und Shink (ich war der Gast mit dem nicht lächerlich machen), es nützt nichts immer mit erhobenem Zeigefinger umher zu wandern, du siehst ja, dass es zu nichts führt, wenn man keine entsprechenden Alternativen aufzeigt. Das Kredo der Objektorientierung ist doch, dass es einem zwar viel handwerkliches in Form von Werkzeugen und Design-Patterns in die Hand gedrückt wird, aber man nach wie vor selbst entscheiden und darüber nachdenken muss, wann es sinnvoll einsetzbar ist und wann nicht. Da nützen keine Pauschalisierungen. Selbstverständlich muss man auf das Ein oder Andere hinweisen, aber man muss es nicht gleich manifestieren.

[Shink]

Selbstverständlich muss man auf das Ein oder Andere hinweisen, aber man muss es nicht gleich manifestieren.
Macht man aber. In jeder modernen Sprache werden Dinge verbannt die man als verpönt ansieht auch wenn sie absolut Sinn machen und unverzichtbar erscheinen: In Java z.B. Steuerung des Pointerhandlings, Mehrfachvererbung u.v.m

Und wenn man sich Sachen wie "Go" ansieht: Da kommt wohl in Zukunft noch einiges auf uns zu.

Ich finde das nicht per se schlecht, auch wenn es sich zugegebenermaßen auch mal ändern kann was verpönt ist und was nicht.

[pest]

ich benutze static gern :freak: - als Hinweis für den Compiler

"lerne" gerade Python (http://de.wikipedia.org/wiki/Python_%28Programmiersprache%29) und als eingefleischter C-Programmierer habe ich damit so meine Schwierigkeiten, und Programmieranfänger machen mir was vor :eek:

[Der_Donnervogel]

Macht man aber. In jeder modernen Sprache werden Dinge verbannt die man als verpönt ansieht auch wenn sie absolut Sinn machen und unverzichtbar erscheinen: In Java z.B. Steuerung des Pointerhandlings, Mehrfachvererbung u.v.mIch bin mir nicht so sicher ob solche Dinge unbedingt an "verpönt oder nicht" festgemacht werden kann. Viele solche Dinge entstammen komplexen Designüberlegungen, die über ein einzelnes Feature hinaus gehen. Beispielsweise gibt es in Java durchaus Mehrfachvererbung. Es gibt sie zwar nicht bei Klassen, aber sehr wohl bei Interfaces. Wenn also Mehrfachvererbung einfach nicht drinnen wäre weil sie verpönt ist, hätte man sie auch bei Interfaces konsequenter weise weg lassen müssen. Denn Sachen wie das Diamanten Problem kann man auch mit Interfaces erzeugen.

[Tesseract]

Mich wundert dein "Grundobjekt". Und das "In Wahrheit nutzen". Kommt mir komisch vor.

mir ist kein besserer begriff dafür eingefallen aber offenbar hab ich da eh was verwechselt. war das vielleicht bei c++ so?

[Neomi]

war das vielleicht bei c++ so?

Definitiv nicht, in C++ gibt es keine Grundobjekte (sofern nicht manuell so implementiert). Statische Eigenschaften und Methoden sind nichts weiter als globale Variablen und Funktionen, die sich allerdings im Namespace der Klasse befinden und im Fall der statischen Methoden auch noch volle Zugriffsrechte auf die Interna von Instanzen der Klasse haben.

[Abnaxos]

Interessant, etwas wird zum Anti-Pattern deklariert, weil man nicht selbst in der Lage war vorab zu erkennen, wann etwas unabdingabar ein Singleton sein muss und wann nicht. Nur zur Info: Man muss nicht immer alles verwenden, nur weil man mal davon gehört hat. Die Regel sollte sein, nur dann etwas zu verwenden, wenn man es auch verstanden hat.
Du fährst dich schneller in eine Sackgasse, als du denkst, wenn du Singletons verwendest. Sollte dir das nie passiert sein, kann das auf zwei Dinge hinweisen:


Du versuchst niemals, Funktionalität, die du schon einmal implementiert hast, erneut zu verwenden.
Du versuchst niemals, Applikationen in andere einzubetten.


Das Singleton-Pattern ist in beiden Fällen Gift. Das macht dir deine ganze schöne Applikation kaputt. In Letzterem Fall sogar ganz sicher, du wirst in meinem Code einige lustige Workarounds um diese Missgeburt von SPI-Framework finden, das Sun mit JDK 1.3 eingeführt hat, um z.B. meine Applikation mitten in NetBeans starten zu können, um eine DataSource für iReport zur Verfügung zu stellen, mit dem Ziel, dass nicht ein hochgradig ausgebildeter Programmierer sich hinsetzen muss, um Reports zu designen. Dann ist die Applikation plötzlich eine Datenquelle und es müssen beliebig viele davon in einer VM koexistieren können. (Kleine Bemerkung: Als ich dieses konkrete Beispiel gebaut habe, hatte ich das alles schon vor ein paar Jahren gelernt, ging sehr gut über die Bühne)

Ich gebe dir soweit Recht, dass ich von Anfang an hätte erkennen sollen, dass man niemals davon ausgehen darf, dass die eigene Applikation die einzige in der VM sein soll, sondern dass es auch noch andere geben kann – immer mal wieder andere Instanzen derselben Applikation. Da ist es natürlich doof, wenn man einen Singelton baut. Ebenso, wenn man die Funktionalität eines Singleton für einen spezifischen Fall ein klein wenig anders konfiguriert verwenden will.

Und wer jetzt merkt, was ich in meiner Argumentation ausgelassen habe, kriegt einen Keks. ;) Punkt 2 lässt sich nämlich ganz gut auf andere Weise ausräumen, erfordert allerdings etwas Gebastel und Verletzung von einigen Verträgen, ist aber im Grossen und Ganzen unbedenklich (aber ziemlich intransparent).

Aber wir schweifen ab …

[Gast]

Wenn also Mehrfachvererbung einfach nicht drinnen wäre weil sie verpönt ist, hätte man sie auch bei Interfaces konsequenter weise weg lassen müssen. Denn Sachen wie das Diamanten Problem kann man auch mit Interfaces erzeugen.
So, jetzt bin ich aber mal neugierig. Wie soll das funktionieren?

Grüße

[Gast]

Du fährst dich schneller in eine Sackgasse, als du denkst, wenn du Singletons verwendest. Sollte dir das nie passiert sein, kann das auf zwei Dinge hinweisen:


Du versuchst niemals, Funktionalität, die du schon einmal implementiert hast, erneut zu verwenden.




Ich kann dir ehrlich gesagt, so gar nicht folgen. Reden wir jetzt über Wiederverwendbarkeit oder über Singletons? Irgendwie verwirren mich deine Satzkonstrukte, sorry.

[Shink]

Viele solche Dinge entstammen komplexen Designüberlegungen, die über ein einzelnes Feature hinaus gehen. Beispielsweise gibt es in Java durchaus Mehrfachvererbung. Es gibt sie zwar nicht bei Klassen, aber sehr wohl bei Interfaces.
Vererbung mit Interfaces ist nunmal nie böse.:freak:
Wenn man ganz konsequent gewesen wäre hätte man gleich Subclassing verbannen müssen aber da wären die GUI-Typen wohl auf die Barrikaden gestiegen (auch wenn man z.B. in SWT sieht dass man durchaus auch dort mit Interfaces auskommt).

[Gast]

Denn Sachen wie das Diamanten Problem kann man auch mit Interfaces erzeugen.
Kommt da noch was, oder haben wir nur bißchen Bullshit-Bingo mit Begriffen gespielt, von denen wir keine Ahnung haben?

Nochmal die Frage:
Konstruiere mir bitte mit Java-Interfaces einen Fall, wo das Diamond-problem zuschlägt.

[Der_Donnervogel]

Kommt da noch was, oder haben wir nur bißchen Bullshit-Bingo mit Begriffen gespielt, von denen wir keine Ahnung haben?

Nochmal die Frage:
Konstruiere mir bitte mit Java-Interfaces einen Fall, wo das Diamond-problem zuschlägt.Kann ich machen, z.B:

public interface A {
int a = 4;
}
public interface B extends A {
int a = 6;
}
public interface C extends A {
int a = 10;
}
public class Test implements B, C {
public void test() {
System.out.println(a);
}
}
So lange man Interfaces nur verwendet um Methodensignaturen zu definieren, gibt es das Problem nicht. Allerdings beschränken sich Interfaces in Java nun mal nicht darauf. Somit kann man das Diamantenproblem auch mit Java erzeugen. Sofern man will.

[Pinoccio]

Kann ich machenVerweigert der Compiler.

public interface A {
int a = 4;
}
public interface B{
int a = 6;
}
public class Test implements A, B {
public void test() {
System.out.println(a);
}
}geht schon nicht.

s4OT

mfg

[Der_Donnervogel]

Verweigert der Compiler.Das ist auch so gedacht. Der Compiler kann nicht compilieren da es nicht eindeutig ist was er verwenden soll. Also vielleicht bin ich komplett verwirrt, aber AFAIK ist das ja gerade das Diamanten Problem. Durch die Mehrfachvererbung entsteht das Problem dass nicht mehr eindeutig ist welche Version vom Compiler verwendet werden soll. Genau darüber beschwert sich dann ja der Java Compiler, da es nicht mehr eindeutig ist welche Version von "a" er verwenden soll.

Da ich mich aber zuletzt im Studium mit solchen Dingen beschäftigt habe, will ich nicht ausschließen, dass ich hier vielleicht etwas daneben liege. Muss ich mir, wenn ich Zeit habe, mal genauer durch den Kopf gehen lassen.

[Matrix316]

Ich weiß ja net ob das in Java anders ist, aber in C# finde ich static prima. Denn anstatt jedes Mal ein Objekt der Klasse zu machen um eine Methode aufzurufen, finde ich Klasse.Methode praktischer.

[Der_Donnervogel]

Ich weiß ja net ob das in Java anders ist, aber in C# finde ich static prima. Denn anstatt jedes Mal ein Objekt der Klasse zu machen um eine Methode aufzurufen, finde ich Klasse.Methode praktischer.Vielleicht verstehe ich den Satz nur falsch, aber das hört sich nach funktionaler Programmierung und nicht nach objektorientierter Programmierung an. Man kann zwar auch Java unter Verwendung von static Funktionen und Variablen praktisch wie eine funktionale Sprache programmieren, allerdings ist das sehr unüblich.

[Monger]

Ich weiß ja net ob das in Java anders ist, aber in C# finde ich static prima. Denn anstatt jedes Mal ein Objekt der Klasse zu machen um eine Methode aufzurufen, finde ich Klasse.Methode praktischer.
Das macht aber nur dann wirklich Sinn, wenn die Methode auf keine Eigenschaften der Klasse zugreift, oder es nichts ausmacht wenn diese Eigenschaft nur ein einziges mal existiert (Singleton). Das ist aber in einer objektorientierten Sprache eher die Ausnahme denn die Regel.

[Gast]

Wenn man den Code schön in Methoden organisiert, dan trifft man static Methoden viel häufiger an, als viele hier denken.

1.) Man hat sehr oft eine Hilfsfunktion, die man nur in einer Klasse benötigt, aber die selbst nicht auf die Varialben der Klasse zugreifen muss, da alle relevanten Informationen übergeben werden. Diese Hilfsfunktionen sind oft auch nur private.

2.) Oft bündelt man Methoden zu einer Klasse, obwohl es gar keinen Sinn macht davon eine Instanz zu erzeugen. Ein Beispiel dafür wäre eine Funktion, die zwei Byte Arrays zusammenfügt und das zurückgibt. Das braucht man relativ häufig. Die Klasse könnte man dann ByteArrayCombiner nennen und die Funktion dafür heißt CombineByteArrays(Array1,Array2). Wenn man das ganze static deklariert, so braucht man dafür keine Instanz (wozu auch).

3.) Ein typisches Beispiel für Static Variablen wären bei mir die Konfiguration des Programms bzw. die Logeinträge des Programms, die dann gesammelt in eine Textdatei geschrieben werden sollen. Dafür habe ich die Klasse Environment. Der Sinn ist hier genau der, dass die Informationen hier gesammelt für alle Programmteile und Threads da sind.

4.) Eine typische Konstallation ist auche eine statische Methode einer Klasse, die eine Instanz der Klasse zurückgibt. In vielen Fällen lässt sich das besser über einen Konstruktor realisieren, aber in manchen Fällen geht das eben nicht z.B. wenn man mehrere dieser Funktionen mit den selben Parametern hat, die aber ganz unterschiedliche Dinge tun oder weil es aus diversen Gründen nicht wirklich passt. In .NET wäre hier ein gutes Beispiel DateTime.Now. DateTime ist hier eine Struktur und Now liefert die aktuelle Zeit. Ein Konstruktor new DateTime ohne Parameter würde zwar technisch den selben Zweck erfüllen, ist aber nicht sehr einleuchtend.

P.S.: Der Sinn eines Interfaces ist es einfach nur Prototypen für Methoden zu deklarieren, die dann implementiert werden. Konkrete Definitionen von Variablen haben hier nichts verloren und mir fällt auch spontan kein Anwendungsfall ein, wo das nicht eine schwere verunglimpfung der Sprache wäre.
Wer verzweifelt versucht eine Mehrfachvererbung herbeizuführen, der sollte sich fragen, ob er wirklich eine IS-A Beziehung hat und keine HAS-A. Wenn man auf Urlaub fährt, ist es auch besser einen Koffer zu haben, als ein Koffer zu sein.

[Matrix316]

Vielleicht verstehe ich den Satz nur falsch, aber das hört sich nach funktionaler Programmierung und nicht nach objektorientierter Programmierung an. Man kann zwar auch Java unter Verwendung von static Funktionen und Variablen praktisch wie eine funktionale Sprache programmieren, allerdings ist das sehr unüblich.
Im Prinzip schon. Aber es verbietet ja keinem in c# oder java das so zu machen. :) Wobei ich hauptsächlich Webanwendungen mit ASP.NET mache und eine Seite im Codebehind schon ne Klasse quasi hat in der man den Hauptcode schreibt, während ich für die Millionen Hilfs"funktionen" für DB Zugriff und sowas hauptsächlich static nutze, um eben nicht dauernd blablabla = new blablabla machen zu müssen. Naja, ist glaube ich doch ein wenig anders als normale Windows Programmierung. ;)

[Expandable]

Vielleicht verstehe ich den Satz nur falsch, aber das hört sich nach funktionaler Programmierung und nicht nach objektorientierter Programmierung an. Man kann zwar auch Java unter Verwendung von static Funktionen und Variablen praktisch wie eine funktionale Sprache programmieren, allerdings ist das sehr unüblich.

Mit funktionaler Programmierung hat das nicht viel zu tun (siehe z.B. Haskell, LISP, F#). Das ist eher klassische imperative Programmierung im C-Stil aufgebläht durch die Verwendung von statischen Klassen mit statischen Funktionen, statt einfach nur globalen Funktionen. Aber richtig, mit Objektorientierung hat das mal primär nichts zu tun.

[Der_Donnervogel]

Mit funktionaler Programmierung hat das nicht viel zu tun (siehe z.B. Haskell, LISP, F#). Das ist eher klassische imperative Programmierung im C-Stil aufgebläht durch die Verwendung von statischen Klassen mit statischen Funktionen, statt einfach nur globalen Funktionen. Aber richtig, mit Objektorientierung hat das mal primär nichts zu tun.Ja, funktional war natürlich der komplett falsche Begriff. Eigentlich hatte ich prozedurale Programmierung gemeint. Ich habe ab und zu das Problem, dass ich die Begriffe "Funktion", "Prozedur" und "Methode" bunt durcheinander würfle, weil alle eine ähnliche Bedeutung haben.

[Gast]

Ich habe ab und zu das Problem, dass ich die Begriffe "Funktion", "Prozedur" und "Methode" bunt durcheinander würfle, weil alle eine ähnliche Bedeutung haben.

Ja so etwas kommt vor. Die Unterschiede sind dann aber doch größer als man meinen mag.

[Matrix316]

Und am Ende sind Methoden auch nur Funktionen und Klassen Structs die auch Funktionen enthalten können. :) Warum man da überhaupt einen Unterschied macht, das verwirrt doch nur.

[Monger]

Und am Ende sind Methoden auch nur Funktionen und Klassen Structs die auch Funktionen enthalten können. :) Warum man da überhaupt einen Unterschied macht, das verwirrt doch nur.
Argh!
Nein, ich fang jetzt nicht an, sonst artet das wieder in einem OOP Glaubenskrieg aus! ;)

[Shink]

Nein, ich fang jetzt nicht an, sonst artet das wieder in einem OOP Glaubenskrieg aus! ;)
Warum eigentlich? Technisch ist da tatsächlich nicht allzu viel unterschied. Was man von der Architektur her daraus macht ist ein anderes Bier. Man kann ja auch mit Structs OOP machen.

Ich habe ab und zu das Problem, dass ich die Begriffe "Funktion", "Prozedur" und "Methode" bunt durcheinander würfle, weil alle eine ähnliche Bedeutung haben.
Das schöne ist dass die Programmiersprachen da tatsächlich die Namen anders verwenden.
Java-Methoden, Pascal-Functions, Pascal-Procedures, C-Functions...

[Gast]

Und am Ende sind Methoden auch nur Funktionen und Klassen Structs die auch Funktionen enthalten können. :) Warum man da überhaupt einen Unterschied macht, das verwirrt doch nur.

1.) Methoden und Funktionen sind nicht nur ähnlich, sondern dasselbe. Die C Programmierer nennen es Funktion, die Java Programmierer Methode. Mit objektorientiert oder nicht hat das jedoch nichts zu tun.
In VB.NET deklariert man eine (nicht statische) Methode sogar als Public Function FunctionName, wenn die Funktion einen Rückgabewert hat.

2.) Das wissen zwar nicht so viele Leute, aber Strukturen können in C sehr wohl Funktionen haben. In VB.NET können sie sogar einen Konstruktor haben (siehe z.B. die Struktur DateTime). Der Unterschied liegt eigentlich nur an der Vererbung. Das ist zwar ein wichtiges Feature der objektorientierten Programmierung, aber im Großteil der Klassen wird das nicht benötigt. Wenn man will, kann man auch in klassichem C objektorientiert programmieren. Das macht zwar kein Mensch, aber es ist möglich.

[Coda]

Das wissen zwar nicht so viele Leute, aber Strukturen können in C sehr wohl Funktionen haben.
Können sie nicht.

[Der_Donnervogel]

In VB.NET deklariert man eine (nicht statische) Methode sogar als Public Function FunctionName, wenn die Funktion einen Rückgabewert hatIch glaube VB ist da kein besonders gutes Beispiel. Denn da kommt so viel ich weiß sogar noch ein Begriff ins Spiel. Der Gegenpart von FUNCTION ist dort nämlich SUB und das kommt, wenn ich mich recht erinnere, von "Subroutine". Bei den alten BASIC-Varianten hat es ja keine echten Methoden gegeben. Dort waren es Sprünge mit GoSub/Return (wenn man mal GoTo außen vor lässt) und da kommt das SUB her.
Das wissen zwar nicht so viele Leute, aber Strukturen können in C sehr wohl Funktionen haben.Können sie nicht.Jein, man kann nicht direkt Funktionen drinn haben, aber man kann Function-Pointer drinn haben. Im Studium haben wir damit mal objektorientierte Programmierung unter C nachbauen müssen. Ist zwar umständlicher als in C++, aber prinzipiell funktioniert es.

[Yavion]

Und am Ende sind Methoden auch nur Funktionen und Klassen Structs die auch Funktionen enthalten können. :) Warum man da überhaupt einen Unterschied macht, das verwirrt doch nur.

Das ist einfach eine präzisere Ausdrucksweise. Eine Methode ist eine Funktion, wenn sie einen Wert hat. Wenn nicht, dann ist es eine Prozedur.
In Pascal hiessen die Dinger auch analog, in C gibt es sie so nicht.
In Java usw hat man sich dann "void" ausgedacht und spricht häufig nur noch von Methoden. Also alles durchaus konsequent und nachvollziehbar. Wenn jemand z.B. in C# seine voids als Funktionen bezeichnet, ist es zumindest falsch.

Ein record oder struct mit Methoden ist mir noch nicht untergekommen. Es mag sein, dass es sowas in irgendeiner Sprache gibt.

[Der_Donnervogel]

Ein record oder struct mit Methoden ist mir noch nicht untergekommen. Es mag sein, dass es sowas in irgendeiner Sprache gibt.Wie gesagt, in C kann man so etwas in der Art mit Function-Pointern machen:
#include <stdio.h>

struct number {
int val;
void (*set) (struct number*, int);
int (*get) (struct number*);
};
void number_set(struct number* this, int value) {
this->val = value;
};
int number_get(struct number* this) {
return this->val;
};
struct number* number_constructor(int value) {
struct number* this = malloc(sizeof(struct number));
this->set = &number_set;
this->get = &number_get;
this->set(this, value);
return this;
};

int main() {
struct number* val1 = number_constructor(5);
struct number* val2 = number_constructor(10);
struct number* val3 = number_constructor(val1->get(val1) + val2->get(val2));
printf("Number = %d", val3->get(val3));
return 0;
}

Die struct enthält sowohl attribute, als auch die dazu passenden Methoden. Irgendwie geht das aber noch besser. Ich glaube es braucht noch eine weitere Indirektion bei der Klasse. Es ist einfach schon zu lange her, dass ich das im Studium gemacht hatte und mit C hatte ich seither sowieso nichts mehr am Hut. Aber auf jeden Fall kann man damit Objektorientierung nachbauen, sogar mit Vererbung usw.

[Gast]

1.) VB.NET ist von der Syntax bestenfalls leicht an Basic/Visual Basic angelehnt, so wie Java/C# an C, aber nicht mehr. Das merkt man spätestens, wenn man meint, dass man seinen alten VB6 Code einfach mit dem VB.NET Compiler übersetzen lassen will. Da merkt man ziemlich schnell, dass das nicht geht.

2.) Strukturen können in C sehr wohl Funktionen haben, auch ohne den Umweg über Function Pointer, allerdings erst in C++. Man kann einfach die Funktionen direkt als Prototyp im struct deklarieren, so wie bei einer Klasse.

[Neomi]

[...] können in C sehr wohl [...], allerdings erst in C++.

Na was denn nun? In C geht es nicht ohne den Umweg über Funktionspointer. In C++ natürlich schon, aber eine struct in C++ ist auch nicht identisch zur struct in C. In C++ ist eine struct nichts anderes als eine class mit public als Defaultzugriffsberechtigung. Weitere Unterschiede gibt es da nicht.

[Der_Donnervogel]

1.) VB.NET ist von der Syntax bestenfalls leicht an Basic/Visual Basic angelehnt, so wie Java/C# an C, aber nicht mehr. Das merkt man spätestens, wenn man meint, dass man seinen alten VB6 Code einfach mit dem VB.NET Compiler übersetzen lassen will. Da merkt man ziemlich schnell, dass das nicht geht.VB.Net ist nicht voll kompatibel zu älteren Basicvarianten, aber durchaus noch ein Basic. Es stecken sogar noch ganz altertümliche Sachen drinn. z.B. kann man wenn man will immer noch

On Error GoTo

für die Fehlerbehandlung benutzen. Anders rum gefragt, was macht denn überhaupt ein Basic aus, damit es sich Basic nennen darf?

[Coda]

Jein, man kann nicht direkt Funktionen drinn haben, aber man kann Function-Pointer drinn haben.
Das ist aber äußerst unschön, weil man damit in *jeder* Instanz sinnlos Speicher verbraucht.

[Gast]

Das ist aber äußerst unschön, weil man damit in *jeder* Instanz sinnlos Speicher verbraucht.

Dafür hat man gleich quasi eine VTable. Man könnte prinzipiell Object-Based Polymorphie betreiben, anstatt Type-Based Polymorphie ;-)

Naja, die Aussage ist nicht ganz ernst zu nehmen, denn so ein Mechanismus wiederspricht jeglicher Form der Objektorientierung.

Objektorientierung spiegelt sich eben nicht nur darin, ob gewisse Dinge mit C emulierbar sind, sondern auch darin, dass man durch die Sprache unterstützt wird. Ein DTOR ist z.B. durch C nicht emulierbar.

[Der_Donnervogel]

Das ist aber äußerst unschön, weil man damit in *jeder* Instanz sinnlos Speicher verbraucht.Das ist natürlich unschön. Es ging ja nur um die Frage ob es prinzipiell geht und nicht darum ob die Lösung auch schön ist. Außerdem kann man die Lösung noch verfeinern (siehe unten).
Dafür hat man gleich quasi eine VTable. Man könnte prinzipiell Object-Based Polymorphie betreiben, anstatt Type-Based Polymorphie ;-)Man kann das in C auch noch weiter treiben. Man speichert die Function-Pointer nicht direkt in den "Instanzen", sondern nur einen Pointer auf die "Klasse", also die struct die die Funktionen enthält. Auf die Art teilen alle "Instanzen" die selben Funktionen und es ist wirklich Type-Based Polymorphie möglich und es wird kein Speicher verschwendet.
Naja, die Aussage ist nicht ganz ernst zu nehmen, denn so ein Mechanismus wiederspricht jeglicher Form der Objektorientierung.

Objektorientierung spiegelt sich eben nicht nur darin, ob gewisse Dinge mit C emulierbar sind, sondern auch darin, dass man durch die Sprache unterstützt wird. Ein DTOR ist z.B. durch C nicht emulierbar.Man kann auch Constructor/Destructor emulieren, wenn man etwas Hand anlegt. Man muss dazu die Funktionen "new" und "delete" selbst implementieren. "new" benötigt als Parameter den Typ der Klasse von der man ein Objekt erstellen will. Die Funktion muss dann eine Instanz erzeugen und führt den Constructor aus, anschließend gibt sie den Pointer auf die Instanz zurück. "delete" wiederum macht das Gegenteil. Es erhält als Parameter die Instanz die gelöscht werden soll. "delete" ruft dann den destructor auf. Wenn man sich bei der Speicherverwaltung noch etwas mehr Mühe gibt, kann man sogar eine automatische Speicherverwaltung mit Garbage-Collector bauen. Ist prinzipiell alles kein Problem. Es macht meistens bloß keinen Sinn. Es ist dann besser gleich eine Sprache zu verwenden die das alles direkt unterstützt.

[Brillus]

Mal wieder zurück zum Theme warum static in Java:

Mehrere Beispiele, Factroy Pattern wurde ja schon gesagt.
Des weiteren sparen static methoden Overhead(kein vtable lookup, ein Paramter weniger der kopiert werden muss(This-pointer). Keine Extra Objecte die dafür angelgt werden müssen. (Stichwort java.lang.Math).

Stichwort Singelton. Wo ich es zumindest oft benutze ist wenn die Singelton Klasse eine Resource kapselt die entweder nur einmal vorhanden ist oder von der Anwendung nur 1 mal verwendt werden darf.

Und erst vor kurzen hatte ich es auch static methoden und attribute gebraucht für ein Projekt, da habe ich halt bei einigen Klassen die Eigenschaft benötigt das wenn 2 Objekte mit den gleichen Parametern konstruiert werden(static Type create(*)) muss die gleiche refernenz zurückgeben werden.

[Shink]

Mehrere Beispiele, Factroy Pattern wurde ja schon gesagt.
Genaugenommen kann man im Factory-Pattern gar keine statische Methode verwenden.:rolleyes:
http://de.wikipedia.org/wiki/Fabrikmethode

Macht ja auch nur halb soviel Spaß wenn man nicht (und sei es bei den Tests) auch eine andere Implementierung der Factory verwenden darf.

Des weiteren sparen static methoden Overhead(kein vtable lookup, ein Paramter weniger der kopiert werden muss(This-pointer). Keine Extra Objecte die dafür angelgt werden müssen.
Tja, "nutzt nur statische Methoden unter Java denn sie sind schneller" war schon immer eines der Hauptargumente für Freunde von static.

Und erst vor kurzen hatte ich es auch static methoden und attribute gebraucht für ein Projekt, da habe ich halt bei einigen Klassen die Eigenschaft benötigt das wenn 2 Objekte mit den gleichen Parametern konstruiert werden(static Type create(*)) muss die gleiche refernenz zurückgeben werden.
Also ein Registry Pattern?

[Yavion]

Jemand hat ja schon gute Beispiele für sinnvollen Einsatz von statics gebracht: Z.B Konfigurationsdaten.

Singleton finde ich z.B. innerhalb eines state-Patterns nicht verkehrt.

[Gast]

Aber wie gesagt, der Vereinfachung halber kann man das ignorieren und die Klasse selber als Objekt betrachten.

Das stimmt so nicht ganz. Jede Klasse ist ein Objekt der Klsse "class". Allerdings verwendet man das beim aktiven Programmieren so gut wie nie, sodass man
das eigentlich nicht mehr lernt.

[Exxtreme]

Das stimmt so nicht ganz. Jede Klasse ist ein Objekt der Klsse "class". Allerdings verwendet man das beim aktiven Programmieren so gut wie nie, sodass man
das eigentlich nicht mehr lernt.
http://www.tweakpc.de/gallery/data/500/goldene-schaufel1.gif

Die Klasse Class verwendet man schon häufiger in ORM-Frameworks.