Java - Nooby :(

[M@tes]

Hab bisher sehr gut mit Perl programmieren können, allerdings blick ich bei Java nicht ganz durch. Das ganze mit den Objekten, vererben etc pp.
Das Grundprinzip hab ich ja verstanden. Theorie... Aber praktisch hab ich noch so meine Mühe.

Könnte mir mal jemand verständlich erklären, was z.B. "static", "abstract" oder "final" bedeuten ohne gleich mit Fachbegriffen umherzuwerfen?

Beispielprogramm:

public static String Text = "TEXT";
public static int Nr = 3;

Gui Output = new Gui();
Output.Console(Nr); // geht nicht
Output.Console(Text); // geht?!?!?!?!

Wieso kann ich da einen String übergeben, aber keine Zahl?
Java stinkt irgendwie gewaltig :P
Is ja schlimmer als Perl.
Jo haut mich ruhig,... Is halt derzeit meine Meinung. :rolleyes:

[HellHorse]

"static"
gehört zur Klasse

"abstract"
Wird irgendwo sonst implementiert.
"final"
Lässt sich nicht mehr ändern.

bedeuten ohne gleich mit Fachbegriffen umherzuwerfen?
Prosa genug?

Wieso kann ich da einen String übergeben, aber keine Zahl?
Vermutlich weil der Typ der die Methode geschrieben hat gesagt hat der will einen String. :rolleyes:

[Coda]

gehört zur Klassestatic sagt doch eher, dass alle instanzen dieser Klasse den gleichen Wert haben für dieses Feld.

Output.Console(Nr);Java ist Typesafe. Du must den Integer zuerst in einen String konvertieren, also (wenn ich mich richtig erinnere):

Output.Console(Integer.toString(Nr));

[Monger]

Könnte mir mal jemand verständlich erklären, was z.B. "static", "abstract" oder "final" bedeuten ohne gleich mit Fachbegriffen umherzuwerfen?

Ich mach's ein kleines bißchen ausführlicher...

"static" markiert Klassenmethoden und Klassenattribute. Das heißt, sie können direkt auf dem Klassennamen ausgeführt werden: "MeineKlasse.Text = "Bla""
Da eine Klasse immer und überall bekannt ist, kann man jederzeit darauf zugreifen - ganz im Gegensatz zu Objekten.
Betrachte "static" einfach als Schlüsselwort für globale Variablen und Methoden...

"abstract" ist ein Begriff aus der Vererbung. Eine "abstrakte" Klasse ist eine Klasse, von der es keine reale Umsetzung gibt. Am besten erklärt man das mit der deutschen Sprache: wir haben viele Begriffe für Dinge, die es gar nicht gibt. 'Gewalt' an sich z.B. ist ein Oberbegriff, der für sich alleine gar nicht existiert. Es gibt psychische Gewalt, physische Gewalt, politische Gewalt usw. , aber Gewalt an sich ist ein abstrakter Oberbegriff.
Genauso ist es bei Java: es gibt keine realen Umsetzungen (=Objekte) von abstrakten Klassen, aber von deren "Kindern".

"final" markiert Konstanten, also Werte die sich nie ändern. Sie können nur ein einziges Mal festgelegt werden, und das nur zur "Geburt" ihres Besitzers. "Math.PI" ist z.B. eine Konstante mit dem Wert der Zahl Pi.


Wieso kann ich da einen String übergeben, aber keine Zahl?

Frag den Entwickler deiner GUI. Aber eine Zahl ist nunmal etwas völlig anderes als ein Text. Logisch betrachtet kannst du keine Zahlen direkt darstellen, sondern nur Textrepräsentationen deiner Zahl. Eine "3" kann man mit völlig verschiedenen Zeichen darstellen. Im Prinzip spricht nichts dagegen, das ganze als römische Zahl, mit Strichen oder mit was ganz absurdem darzustellen.
Bei uns haben sich die arabischen Zahlen nunmal durchgesetzt, deshalb ist für uns eine Zahl und ihr Schriftbild gleichbedeutend. Java muss aber immer diese Wandlung machen. Oft genug macht es das still und heimlich im Hintergrund, aber eben nicht immer.

[HellHorse]

static sagt doch eher, dass alle instanzen dieser Klasse den gleichen Wert haben für dieses Feld.
Nein, es sagt, dass es zur Klasse gehört, funktioniert also auch ganz ohne Instanzen. Alle Instanzen einer Klasse (oder Subklasse) greiffen auf das gleiche Klassenattribut zu. Nicht jede hat ihr einziges.

Beispiele wo static verwendet wird
statische Klassen
static Initializer
Klassenattribute
Klassenmethoden
Also bei weiten nicht auf Felder beschränkt.

@Monger
final gibts auch für Methoden und Klassen

[Hucke]

Java ist Typesafe. Du must den Integer zuerst in einen String konvertieren, also (wenn ich mich richtig erinnere):

ToString funktioniert in Java bei allem, auch ohne Cast. Ob die Ausgabe allerdings sinnvoll ist hängt stark davon ab was man da ausgeben möchte. Bei den primitiven Datentypen ist das allerdings immer ok, wenn auch eventuell in der falschen Lokale.

[Monger]

@Monger
final gibts auch für Methoden und Klassen
Ich weiß. Ich habs nur ausgespart, weil mir deren Sinn selber nicht klar ist.


ToString funktioniert in Java bei allem, auch ohne Cast. Ob die Ausgabe allerdings sinnvoll ist hängt stark davon ab was man da ausgeben möchte. Bei den primitiven Datentypen ist das allerdings immer ok, wenn auch eventuell in der falschen Lokale.


Ich versteh kein Wort. Basisdatentypen haben keine Methoden, also auch kein toString. Und was meinst du mit "der falschen Lokale"?

[Coda]

Nein, es sagt, dass es zur Klasse gehört, funktioniert also auch ganz ohne Instanzen. Alle Instanzen einer Klasse (oder Subklasse) greiffen auf das gleiche Klassenattribut zu. Nicht jede hat ihr einziges.

Beispiele wo static verwendet wird
statische Klassen
static Initializer
Klassenattribute
Klassenmethoden
Also bei weiten nicht auf Felder beschränkt.Äh ich weiß was static ist. Aber "es gehört zur Klasse" ist keine gute Beschreibung dafür. Eine normale Membervariable "gehört auch zur Klasse".

[Hucke]

Ich versteh kein Wort. Basisdatentypen haben keine Methoden, also auch kein toString. Und was meinst du mit "der falschen Lokale"?

Lokale bezieht sich bei den Fließkommazahlen auf das Tausendertrennzeichen. Wenn man eine String Repräsentation eines Fließkommawertes hat, dann spielt immer die Einstellung der Lokalen eine Rolle, da ein Punkt anders gewertet wird als ein Komma.

Und meine Aussage ist wohl nicht ganz korrekt. Es gibt keine toString Methode für die Basistypen, das ist wohl richtig, aber Java konvertiert gern mal autmatisch primitive Datentypen nach String, je nachdem wie man diese benutzt. Es gilt aber wohl als schlechter Stil. Da kann Dir Hellhorse wohl mehr zu sagen, mir reichts wenn mein Programm läuft.

Beispiel:

int nix = 7;
double auchnix = 9;
String testtest = "test "+nix+" soso "+auchnix;
System.out.println(testtest);

Gibt als Ausgabe:
test 7 soso 9.0

[HellHorse]

Aber "es gehört zur Klasse" ist keine gute Beschreibung dafür.
Geht so. Betrachte ein Klasse einfach als eine Instanz einer Metaklasse und eine Klassenvariable als eine Instanzvariable der Klasse.

Was wäre dein Vorschlag für eine Beschreibung des static Modifiers, nicht einer Klassenvariable? Und bitte `ohne gleich mit Fachbegriffen umherzuwerfen'.

Eine normale Membervariable "gehört auch zur Klasse".
Nein, tut sie nicht, sie `gehört zur Instanz' ist auf einem anderen Meta-level.

Das mit dem String hat überhaupt nichts mit typesafe sondern mit dem statischen Typchecker zu tun. Das sind zwei verschiedene paar Schuhe.

[Coda]

Was wäre dein Vorschlag für eine Beschreibung des static Modifiers, nicht einer Klassenvariable? Und bitte `ohne gleich mit Fachbegriffen umherzuwerfen'.Gute Frage, aber bei deiner Erklärung würde ich als Anfänger so meine Schwierigkeiten haben.

Bei Feldern würde ich "globale Variable im Namensraum der Klasse" sagen.

Das mit dem String hat überhaupt nichts mit typesafe sondern mit dem statischen Typchecker zu tun. Das sind zwei verschiedene paar Schuhe.Darüber kann man auch streiten. Für mich ist eine Sprache auch typesafe wenn es nur zur Kompilierzeit geprüft wird.

[Stone2001]

Darüber kann man auch streiten. Für mich ist eine Sprache auch typesafe wenn es nur zur Kompilierzeit geprüft wird.
Kurze Anmerkung: Seit sie in Java 1.5 die Generics eingeführt haben, ist Java auch nicht mehr Typsicher.

[HellHorse]

Darüber kann man auch streiten.
Teilweise, James Gosling z.B. ist anderer Meinung als du.

Für mich ist eine Sprache auch typesafe wenn es nur zur Kompilierzeit geprüft wird.
Was du gerade beschrieben hast ist ein statischer Typchecker. Das alleine reicht bei weiten nicht. Viel wichtiger sind checks zur Laufzeit (und Bytecodeverifikation).
Bsp:

public static int Nr= 3;
public static Object NrObject = new Integer(Nr);

Gui Output= new Gui();
Output.Console((String) NrObject); // Boom!


Kurze Anmerkung: Seit sie in Java 1.5 die Generics eingeführt haben, ist Java auch nicht mehr Typsicher.
Unsinn. Generics können ClassCastExceptions nicht gänzlich verhindern, genausowenig wie das alte Typsystem. Wenn du mit generics eine ClassCastExceptions kriegst, dann bloss in Fällen wo du das mit dem alten Typsystem auch gekriegt hättest. Zudem sind ja gerade ClassCastExceptions ein Zeichen von einem sicheren Typsystem, denn es wird so verhindert, dass gecastet wird, was nicht kompatibel ist.
Im Gegenstatz zu anderen Sprachen wo man casten kann wie einem bliebt und zur Laufzeit dann alles mögliche passieren kann.

[Coda]

Teilweise, James Gosling z.B. ist anderer Meinung als du.Mag sein. Für mich sind C++ und Java typsicher ;)

Und Wiki meint auch, dass es beides gibt:
http://de.wikipedia.org/wiki/Typsicher

Was du gerade beschrieben hast ist ein statischer Typchecker. Das alleine reicht bei weiten nicht. Viel wichtiger sind checks zur Laufzeit (und Bytecodeverifikation).Wie gesagt, kann man sich drum streiten. Ich kenne wenige Fälle wo das wirklich nötig ist. Wenn man Casts verbietet ist es sogar gar nicht nötig.

[Coda]

Kurze Anmerkung: Seit sie in Java 1.5 die Generics eingeführt haben, ist Java auch nicht mehr Typsicher.Nein das ist ein Irrtum. Weder Templates in C++ noch Generics in Java verletzen die Typsicherheit.

[grakaman]

public static int Nr= 3;
public static Object NrObject = new Integer(Nr);

Gui Output= new Gui();
Output.Console((String) NrObject); // Boom![/code]


Naja gut, da gibts freilich ne Exception. Aber es gibt Sprachen, da kann der Compiler Autoboxing und es würde in dem Fall Output.Console(NrObject) ausreichen. Und wenn man schließlich explizit castet, muss man sich darüber im klaren sein. Btw ist doch die Exception ein sehr gutes Bsp. für Typsicherheit, auch wenn sie hier erst zur Runtime auftritt. Laut Wikipedia ist eine Sprache schon typsicher, wenn sie spätestens zur Laufzeit den Fehler bringt. Aber du hast freilich recht, dass es schon optimaler wäre, wenn man alles zur Compilezeit totschlagen könnte. Aber dann müsste man ja auf die ganzen netten Dinge wie Reflections verzichten.

edit: Ich meinte freilich Output.Console(Nr) :redface:

[HellHorse]

Mag sein. Für mich sind C++ und Java typsicher ;)
Und für mich hat ein Byte sieben Bit ;)
Und Wiki meint auch, dass es beides gibt:
http://de.wikipedia.org/wiki/Typsicher
Oft wird fälschlicherweise die statische Typprüfung wegen des angenommenen qualitativen Vorteils gegenüber der dynamischen Typprüfung als „sicher“ bezeichnet.
Folgendes ist aber offensichtlich falsch:
Typsicherheit herzustellen ist Aufgabe des Compilers.

Wenn man Casts verbietet ist es sogar gar nicht nötig.Womit wir wieder einmal bei der Nullaussage wäre, dass ein typsicheres Subset typsicher ist. Und der von dir herangezogene Wikipedia Eintrag sagt auch warum das nicht geht.

[Trap]

Typsicherheit ist von allen Eigenschaften die man bei einem Programm gern hätte sicher eine der unwichtigeren, allerdings eine der wenigen, die man relativ einfach und vollständig automatisch verifizieren kann.

Bestmögliche performance und totale Korrektheit automatisch verifizieren wäre nett ;)

Erster Versuch einer Implementierung, der in weit über 99% der Fälle das richtige ergibt:
false

[M@tes]

Das is eben genau das, womit ich mühe habe. Der Lehrer schmeisst in seinen Dokus mit Begriffen umher und ich hab kein Plan, was er will. Die Unterlagen kann man sowieso knicken :(
Und Zeit fürn Buch hab ich nicht.
Morgen hab ich Prüfung, die ich garantiert in den Sand setze :(
- Was ist z.b. eine Methode? Eine Funktion??
- Was macht eine "abstrakte" Klasse? Führt sie weitere Unterclassen auf?
- Was ist eine Instanz? Quasi Mehrere Programmteile, die parallel laufen?
- Was ist typesafe?

Sry, für die eigentlich sicher dämmlichen Fragen. Imo ists leider notwendig :(
Kam auch erst jetzt dazu auf den Thread zu antworten.

[Trap]

Alles ist das als was es definiert ist.

Im Fall von Java-Begriffen gibt http://java.sun.com/docs/books/jls/ die verbindlichen Definitionen, bei allgemeinen Informatik-Begriffen hilft sehr oft Wikipedia.

Unverbindliche Beschreibung von mir:
-Instanz (einer Klasse) ist ein Objekt dessen Typ die Klasse ist.
-Methode wird je nach Programmiersprache anders definiert, in Java gibt es keine Funktionen, nur Methoden (oder anders gesagt: in Java heißen Funktionen "Methode")
-typesafe == typsicher, auf dinge werden nur Funktionen angewandt die für den Typ des dings definiert sind.

Such nochmal in der Java Spezifikation und Wikipedia und vergleich die Definitionen