static Variablen in Methoden nicht erlaubt?

[SirLant]

Das Topic sagt eigentlich alles, sehe ich das richtig, dass ich static Variablen
nur global in Klassen benutzen kann und nicht innerhalb einer Methode?
Wenn dem so wäre, würde mich Java ja dazu zwingen Variablen die eigentlich als
static in eine Methode gehören, global in der Klasse zu halten, und das kann ich
mir irgendwie nicht vorstellen.

[Gast]

Doch, das ist so. Der Grund dafür ist vermutlich, dass static ein bisschen quer zur Objektorientierung steht. Was willst du denn statisch speichern?

[Gregor]

"Statische Variable" und "in Methode" ist ein Widerspruch in sich. Mit "static" gibt man an, dass eine Variable oder eine Methode (oder etwas ganz anderes) an die Klasse gebunden ist und nicht an ein Objekt. Variablen in Methoden sind lokal und haben weder eine Bindung zur Klasse noch zum Objekt. Sie existieren nur, bis der Block, in dem sie deklariert wurden, verlassen wird.

Was willst du denn mit dem "static" in einer Methode erreichen?

[SirLant]

Ganz einfach ich will vermeiden, dass eine Variable die nur in der Funktion
benötigt wird global in der Klasse stehen muss. In meinen C/C++ Bücher habe ich
immer gesagt bekommen, dass ich alle Variablen so lokal wie möglich halten soll,
und wenn nur eine Methode diese variable zum speichern eines Wertes für sich selbst,
benötigt, dann ist diese am besten als static deklariert in der Methode selbst
aufgehoben.
Aber das geht in Java ja nicht, ich verstehe zwar nicht wieso, aber ich nehme es
mal einfach hin, was anderes bleibt mir auch nicht übrig. Musste jetzt halt ein
Singleton für 2Integer und 1Double verwenden.

[ms@work]

Um java zu programmieren solltest du dein C/C++ Buch gegen ein Java-Buch eintauschen.

Vergiss einfach static in dem Zusammenhang wie du es bisher gekannt hast und deklariere einfach deine Variablen ohne static, dass passt dann schon so.

Ach ja, was sollten die Singletons eigentlich bringen?

ms

[Helium]

ergiss einfach static in dem Zusammenhang wie du es bisher gekannt hast und deklariere einfach deine Variablen ohne static, dass passt dann schon so.

Was soll denn die bescheuerte Aussage? Wenn sie im C Sinn statisch sein soll und das jetzt in Java nachgebildet werden muss, kannst du doch nicht einfach sagen, das er was ganz anderes machen soll.

z.B.

int foo ()
{
   static int x;
   return ++x;
}
int bar ()
{
   int x;
   return ++x;
}

Würde ich foo jetzt dreimal hintereinander aufrufen erhilte ich 1, 2, 3. bei bar würde ich irgendwelche schwachsinnige Zahlen erhalten, da x nicht initialisiert wird.

[CengizS]

Welchen Unterschied würde das in C++ machen? Angenommen man müsste in C++ auch alles in eine Klasse packen. Glaubst du der Aufruf einer Methode, die einen static identifier erhöht und zurückgibt, würde den Identifier pro Objekt erhöhen?

Hier mal ein wenig Code ...

#include "stdafx.h"
#include <iostream>

using namespace std;

class MyClass {
	public:
		int foo() {
			static int x = 0;
			return ++x;
		}
} mc1, mc2;

int main(int argc, char* argv[]) {
	for (int i=0; i<10; ++i) {
		cout << "mc1.foo() = " << mc1.foo() << endl;
		cout << "mc2.foo() = " << mc2.foo() << endl;
	}
	return 0;
}

Was kommt hier raus? Eben keine Aufzählungen von 1..10 für beide Objekte sondern laufende Nummern von 1..20. Ergo könnte man den identifier (das x) also Klassenglobal machen und in den Kopf der Klasse transferieren - so wie es in Java dann wieder möglich wird ... ach ja das Pendant in Java dazu wäre:

public class MyClass
{
	static int x=0;

	public int foo() {
		return ++x;
	}

	public static void main (String args[]) {
		MyClass mc1 = new MyClass();
		MyClass mc2 = new MyClass();
		for (int i=0; i<10; ++i) {
			System.out.println("mc1.foo() = " + mc1.foo());
			System.out.println("mc2.foo() = " + mc2.foo());
		}
	}
}

Wie du siehst: Das selbe in grün.

[Helium]

Ich glaube ich muss mich klarer ausdrücken

ms@work sagte, er solle das static einfach weglassen, was natürlich zu ganz anderen ergebnissen führen würde. Ich wollte ms@work lediglich den Unterschied verdeutlichen.

[Gast]

...

[...]

... ?

[CengizS]

Helium schrieb:

ms@work sagte, er solle das static einfach weglassen, was natürlich zu ganz anderen ergebnissen führen würde. Ich wollte ms@work lediglich den Unterschied verdeutlichen.

Er sagte aber auch, dass man das static im C-Sinne vergessen soll bei der Java-Programmierung und das ist doch die Quintessenz?

[Helium]

Ja.

[SirLant]

Vllt. seht ihr Javaprogrammierer das anderst, aber in meinen Augen hat, die Variable
keinerlei Grund Klassenglobal zu sein, wenn sie nur von der Methode manipuliert
werden soll, so kann ich mir sicher sein, dass kein Zugriff von einer anderen
Methode auf diese Variable geschieht.
Bei ner kleinen Klasse hat man ja den Überblick, wie bei meiner Singleton, aber
bei ner größeren Klasse wo die Übersicht nicht mehr in dem Maße vorhanden ist,
kann sich durch nen kleinen Fehler (z.B. copy n' paste) oder ähnliche Variablen
und nem Tippfehler, oder sonstiges nen Fehler einschleichen den man ewig sucht.
Wäre bei ner statischen Variable in der Methode ausgeschlossen.

[Helium]

*Verallgemeiner und provozier*: Java-Programmierer nehmen's mit der Kapselung nicht so genau

[CengizS]

Netter Verusch
Also ich geb SirLant prinzipiell Recht. Es ist in der Tat möglich aus einer anderen Methode der selben Klasse den static identifier zu verändern.

Wenn man diesen identifier auch noch public lässt dann darf man den sogar von außen (sprich anderen Klassen) aus verändern. Wer dies zuläßt ist aber selbst schuld

Es gibt allerdings die Möglichkeit das static mit einem private zu versehen, womit diese Variable dann wirklich nur noch von den eigenen Methoden der Klasse verändert werden kann. Also wenigstens eine gewisse Sicherheit für den identifier gegeben. Anderen Klassen bleibt der Zugriff auf diese Variable verwehrt also kommt keiner auf die Idee deine Klasse zu untergraben.

<Pfad>\MyClass.java:25: x has private access in MyClass

Ob das hinreichend sicher und gut ist sei mal dahingestellt.

[Bashar]

SirLant schrieb:

Bei ner kleinen Klasse hat man ja den Überblick, wie bei meiner Singleton, aber
bei ner größeren Klasse wo die Übersicht nicht mehr in dem Maße vorhanden ist,
kann sich durch nen kleinen Fehler (z.B. copy n' paste) oder ähnliche Variablen
und nem Tippfehler, oder sonstiges nen Fehler einschleichen den man ewig sucht.
Wäre bei ner statischen Variable in der Methode ausgeschlossen.

Dann sollte man Klassen halt nicht so groß machen, dass man keinen Überblick mehr hat.

[SirLant]

Bashar schrieb:

SirLant schrieb:

Bei ner kleinen Klasse hat man ja den Überblick, wie bei meiner Singleton, aber
bei ner größeren Klasse wo die Übersicht nicht mehr in dem Maße vorhanden ist,
kann sich durch nen kleinen Fehler (z.B. copy n' paste) oder ähnliche Variablen
und nem Tippfehler, oder sonstiges nen Fehler einschleichen den man ewig sucht.
Wäre bei ner statischen Variable in der Methode ausgeschlossen.

Dann sollte man Klassen halt nicht so groß machen, dass man keinen Überblick mehr hat.

Sollte man deshalb besteht meine kleine Schulaufgabe auch aus 3Klassen statt einer,
was ohne Probleme möglich gewesen wäre (wenn man es wirklich übers Herz bringt prozedural in ner OOP Sprache zu arbeiten ).
Aber immer lässt sich der Code nicht einfach verkleinern, da es einfach Dinge
gibt die Platz brauchen und reine Tipparbeit ist.

[Gregor]

SirLant schrieb:

Aber immer lässt sich der Code nicht einfach verkleinern, da es einfach Dinge
gibt die Platz brauchen und reine Tipparbeit ist.

Mich interessiert, was du für "Größenvorstellungen" von einer kleinen, von einer mittleren und von einer großen Klasse hast. ...erzähl mal. (ist etwas OT)

[SirLant]

Ne kleine Klasse ist bei mir eine die auf den Bildschirm passt, max auf zwei
Bildschirme. Wären so knapp 100Zeilen, kommt natürlich auf die Anzahl der Kommentare
an, die gehören ja nicht direkt zum Programm, wobei zu viele Kommentare auch
für eine schlechte Übersicht sorgen können.

Ne mittlere Klasse, hm das ist schwer, mittel ist ja immer so dehnbar.
Würde ne große Klasse so ab 400-500 Zeilen Code ansetzen.
Wobei es dann nen rießigen Unterschied zwischen so 400-500 Zeilen und den 1100Zeilen
von BigDecimal (klar sind viele Kommentare dabei, aber auch diese tragen zur
komplexität bei, da sie teilweise die Übersicht rauben können).

Also ne große Klasse ist bei mir z.B. BigDecimal

Aber es gibt ja auch Klassen wie BigInteger mit 3000 Zeilen Code, das ist nen
gutes Beispiel für ne Klasse wo man einfach Platz braucht ohne dass ein
Designfehler vorliegt.

btw. Finde es gut, dass man mit euch schön diskutieren kann

[Gast]

Eine kleine Klasse ist IMO so etwas:

class Point
{
    Point(int x, int y)
	{
		this.x = x;
		this.y = y;
	}

	final int x;
	final int y;
}

Die Kommentare hab ich rausgenommen, die sind nämlich 2mal so groß wie dieser Code hier, das wäre dann nicht mehr repräsentativ gewesen.

Zu dem static: IMO braucht man es nicht wirklich innerhalb von Funktionen, aber mir ist auch nicht klar, warum das in Java nicht übernommen wurde, genauso wie Templates (die ja jetzt zum Glück kommen).
Man wollte halt die Sprache einfach halten, was sie ja unbestritten auch ist, aber egal. Ich komme selten in die Verlegenheit sowas zu "brauchen".