static Variablen in Methoden nicht erlaubt?

[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".

[SirLant]

Dass C++ ziemlich komplex ist bestreite ich nicht, aber man muss nicht jedes Detail
wissen am Anfang, genau wie ich wunderbar Java programmieren kann ohne alles zu
wissen, aber ich erfahre ja hin und wieder was neues von euch

Die Generics in Java sind aber keine Templates im C++ Sinne, zwischen den Generics
in Java 1.5 und den Templates in C++ liegen Welten.

[Gregor]

Ich habe da auch eher Optimizers Größenvorstellungen. Wenn ich Zeilen angeben müßte, dann würde ich sagen:

kleine Klasse: bis 30 Codezeilen
mittlere Klasse: 30 bis 150 Codezeilen
große Klasse: 150 bis 400 Codezeilen
abnormal riesiege Klasse: mehr als 400 Codezeilen

Wenn man Kommentare und Leerzeilen mitrechnet, dann würden sich diese Zahlen wohl nochmal verdoppeln. Bei einer API würden sie sich sicherlich sogar verdreifachen bis verfünffachen, weil eine API relativ ausgiebig dokumentiert sein muss.

[Shade Of Mine]

Optimizer schrieb:

Die Kommentare hab ich rausgenommen

Wo braucht so eine Klasse Kommentare? Vorallem: was steht in den Kommentaren?

[Gast]

Ist jetzt natürlich ein sehr triviales Beispiel, is halt für unser Praktikum an der FH, da muss ja alles perfekt sein.
Außerdem, wenn das ganze Projekt ausführlich dokumentiert ist, dann gibt es keinen Grund, die eine Klasse nicht zu dokumentieren. Zumal die Klasse von mir selber gar nicht benutzt wird, sondern von anderen.
Vielleicht kommen auch noch Erweiterungen hinzu, das wissen wir noch nicht genau. Ziel sollte es für jede Klasse sein, dass sich keiner den Quellcode anschauen muss.

package battleship;

/** Die Klasse Point repräsentiert Koordinaten auf dem
 *  Spielfeld. Diese bestehen aus einer x- und einer y-
 *  Komponente. Die Datenelemente sind innerhalb des
 *  Package öffentlich abrufbar, aber unveränderbar. Von
 *  dieser Klasse kann <i>nicht</i> mehr abgeleitet
 *  werden.
 *
 *  @author Michael Firbach
 *  @version 1.00
 */
final class Point
{
	/** Konstruktor für ein Point-Objekt.
	 *  @param x Die x-Komponente der Koordinate.
	 *  @param y Die y-Komponente der Koordinate.
	 */
	Point(int x, int y)
	{
		this.x = x;
		this.y = y;
	}

	/** Die x-Komponente dieser Koordinate.
	 *  <i>Unveränderlich</i>.
	 */
	final int x;
	/** Die y-Komponente dieser Koordinate.
	*  <i>Unveränderlich</i>.
	*/
	final int y;
}

[Shade Of Mine]

Wenns für die Schule ist, ist alles erlaubt

Aber ernsthaft würde ich sowas nie machen. Da schreibe ich ja länger an den Kommentaren als an dem Sourcecode...

[Gast]

Ja, das ist natürlich ein sehr extremes Beispiel, weil die Klasse so klein ist.
Allerdings, wenn du einen Blick in den Code der Java-API wirfst, stellst du fest, dass meistens gut 2/3 Kommentierung ist. Der Hintergedanke dabei ist natürlich, dass man keine seperate Dokumentation mehr schreiben muss, so wie die MSDN.

[Shade Of Mine]

Optimizer schrieb:

Allerdings, wenn du einen Blick in den Code der Java-API wirfst, stellst du fest, dass meistens gut 2/3 Kommentierung ist. Der Hintergedanke dabei ist natürlich, dass man keine seperate Dokumentation mehr schreiben muss, so wie die MSDN.

Wobei ich persönlich die MSDN mies finde, aber immer noch besser als die Java Doku

Ne, im ernst: für eine Library sind viele Kommentare OK - wobei ich damit nicht den Quellcode zumüllen würde.

In C++ geht das schön, da man das Interface woanders stehen hat, als die Implementierung. Da stört es IMHO nicht so. Aber wenn ich die Kommentare quasi direkt im Quellcode habe... naja, ich finds halt ungut.

[Gast]

Ich sag dir jetzt lieber nicht, was ich von Header-Dateien halte.