ich muss für die Schule ein Vortrag halten, über "die fundamentalen Klassen von java.lang".
Zur Zeuit habe ich folgende Klassen im Vortrag eingebunden:
die Klasse „Object“
die Klasse „Class“
die Klasse „Math“
die Klasse „Number“
die Klasse „String“
die Klasse „System“
meint ihr(wie ich), dass das die wichtigsten sind, oder habt ihr noch ande Vorschläge?
Definiere "fundamental" ... das ist sicher Ansichtssache. Auch die Klassen der simplen Datentypen wie Integer, Boolean, Long etc. könnte man dazunehmen.
Dann natürlich noch die Ausnahmen wie NullPointerException.
Eigentlich könnte man fast alle als "fundamental" bezeichnen
Wenn du eine Übersicht brauchst, die Java SE API bietet da eine.
Das ist natürlich sehr subjektiv. Thread bildet die Basis für parallele Programmierung. Enum ist die Superklasse aller enums, Throwable das Superinterface aller Ausnahmen. Runtime bzw. Process erlauben z.B., andere Programme aufzurufen.
Andererseits kann man sich auch auf den "Typsystem"-Standpunkt stellen, und nur Object, Class (und vielleicht noch System und ClassLoader) als fundamental ansehen.
Generell denke ich aber, deine Auswahl ist vertretbar.
Achso okay, dann versuche ich snoch ein paar Klassen mehr aufzunehmen(Vortrag darf nur 10-15 minuten dauern)
Aber eine Frage zu den Datentypen habe ich noch, und zwar gibt es im Java.lang Package die Klasse "number", aber auch die Klassen "Integer, Double". in welchen dieser Klassen sind die Datentypen nun enthalten?
also mein(bsp):
"private double zaehler;"
weil in Klasse Number, sowie in Klasse double wird davon gesprochen
Nach welchen Kriterien suchst du die Klassen denn aus? Die sind nämlich alle irgendwie ziemlich wichtig
Klasse Object ist so gesehen überaus wichtig, weil sie die "Mutter" aller Klassen ist (auch von Klasse Class, auch wenn es seltsam wirkt). Klasse Class ist relativ speziell und läuft eher auf einer Metaebene (Aus der API: "Instances of the class Class represent classes and interfaces in a running Java application."), von daher würde ich sie für die Praxis als nicht so wichtig betrachten. System.out.print() bzw. […].println() hingegen gehören wohl zu den am häufigsten benutzten Methoden überhaupt ^^ Math kann man auch für die verschiedensten Situationen gebrauchen, ist also auch ziemlich praxisrelevant. String wird ebenfalls ständig gebraucht, schätze ich. Number ist die Mutterklasse von den Wrapper-Klassen Integer, Double, Float etc., mit denen man beim Autoboxing in Berührung kommt, aber mit der Mutterklasse selbst hat man in der Praxis wohl eher wenig zu tun.
Für erwähnenswert halte ich noch die Klasse Thread, da man um die nicht herumkommt, wenn man mehrere Dinge gleichzeitig tun lassen will.
Naja, denk einfach mal darüber nach, wie du deine Prioritäten setzen willst, und frag ggf. nochmal nach
Kleiner Tipp:
Es gibt bei der Auswahl vermutlich kein richtig oder falsch.
Viel wichtiger wird sein, wie gut du die Klassen beschreibst und nach welchen Kriterien du sie ausgesucht hast. 20 Klassen in eine 10-15 Minuten Präsentation wird dabei eher einen negativen Effekt haben. Nimm lieber weniger Klassen, die du dir gut überlegt ausgesucht hast (ohne Anstoss von außen), begründe deine Auswahl gut und beschreibe gut. Dann wird das ganze schon gehen.
ich belese mich gerade über "Strings" und habe folgenden absatz gefunden:
String literals
In Java code, the String literals are kept in a memory pool for efficient use.
If you construct two Strings using the same String literal without the new keyword, then
only one String object is created. For instance:
String s1 = "hello";
String s2 = "hello";
Here, both s1 and s2 point to the same String object in memory. As we said above,
String objects are immutable. So if we attempt to modify s1, a new modified String is
created. The original String referred to by s2, however, remains unchanged.
Auch wenn Strings in Java Objekte sind, ist dieser Pool, von dem in dem Zitierten die Rede ist, eine kleine Besonderheit von Strings.
Normalerweise erzeugst du Objekte ja so:
Intern (d.h., wie die JVM / der Compiler damit umgeht) besteht jedoch ein Unterschied zwischen den beiden Möglichkeiten. Schau dir folgendes Codestück an:
-Operator nicht verwendet wurde, wird in dem o.g. Pool nur ein einziges Mal die Zeichenkette "hello" abgelegt. Wenn s2 erzeugt wird, sieht der Compiler, dass es den "hello"-String schon gibt, und weist ihn s2 zu, erzeugt aber keinen neuen "hello"-String im Pool. Deshalb kommt sowohl bei der equals()-Methode als auch beim ==-Vergleichsoperator
Code:
true
raus (equals() vergleicht Strings inhaltlich,
Code:
==
nur die Referenzen).
Bei s3 und s4 hingegen werden tatsächlich zwei verschiedene "hello" im Pool abgelegt, s3 zeigt auf das eine, s4 auf das andere. Deshalb kommt zwar beim inhaltlichen Vergleich mit equals()
Code:
true
raus, weil ja bei beiden Zeichenketten das gleiche drin steht, nicht aber beim ==-Operator, da die Referenzen auf unterschiedliche Objekte zeigen.
ich bin schon ein ganzes Stück weiter, nur jetzt hackt es wieder an meinem Englisch skills ...
Wrapper classes correspond to the primitive data types in the Java language. These classes
represent the primitive values as objects. All the wrapper classes except Character have
two constructors -- one that takes the primitive value and another that takes the String
representation of the value. For instance:
Integer i1 = new Integer(50);
Integer i2 = new Integer("50");
The Character class constructor takes a char type element as an argument:
Der Text sagt im wesentlichen nur aus, dass es für alle Wrapper-Klassen (Integer, Long, Double, Float, Boolean, Short, Byte) mit Ausnahme von Character zwei Konstruktoren gibt: Der eine nimmt als einziges Argument das entsprechende primitive Gegenstück an (also z. B. ein int bei Integer), während der andere einen String akzeptiert und versucht, diesen als Stringrepräsentation des entsprechenden Typs zu interpretieren (also z. B. [c]new Integer("42");[/c] -> ein Integer mit dem Wert 42). Character, als einzige Ausnahme, bietet lediglich einen einzigen Konstruktor, welcher ein einzelnes char entgegennimmt.
mhm ... mich wundert dass sie immer noch in den dokus [c]new[/c] nutzen, obwohl fuer die Wrapper Klassen [c]valueOf[/c] gibt die dem Konstruktor vorzuziehen ist...