Originally Posted By: MasterQ32
Originally Posted By: HeelX
Pfui!

Dann erklär mir mal bitte, wieso die toString-Methode von GregorianCalendar so einen Shit ausspuckt.
Wieso int und Integer unterschiedlich sind. Und wieso das Konzept der Objektorientierung nicht 100% durchgezogen wurde


Für Kalendare verwendet man unter Java in der Regel ein konfiguriertes Objekt der Klasse DateFormat, bzw. SimpleDateFormat, um dann ein von einem Calendar erzeugtes Date-Objekt zu formatieren. Das ist auch gut so, da es im Allgemeinen kein einheitliches Format für Kalendarangaben gibt und auch von Anwendungsfall zu Anwendungsfall variiert. Bestes Beispiel ist wohl die Vertauschung von Monat und Tag, aber auch Formate wie "YYYY-MM-DD" für Dateibenennung oder die AM/PM Geschichte sind üblich. Die toString Methode von GregorianCalendar druckt im Prinzip nur alle Attribute aus, und das sind nicht nur AD und BC wie in der Doku steht, sondern auch und insbesondere die der Oberklasse Calendar, sowie die Konfiguration des Kalendars.

Integer ist in diesem Fall eine Envelope Class für den primitiven Datentyp int und verpackt den Wert in einem echten Objekt und kann daher auch == null sein. In Java ist alles objektorientiert und deshalb kannst du z.B. keine Primitive in Containern aufnehmen. Wenn du eine Methode aufrufst und ne int übergibst und eine Integer erwartet ist, auto-boxed Java das dann für dich in ein Integer-Objekt und andersherum. Zusätzlich zu dieser Eigenschaft bieten die Wrapper-Klassen Funktionen zum Zugriff auf den Wert und einige Umwandlungsfunktionen. Es ist natürlich streitbar, warum es dann zwei "Sorten" gibt, aber beide haben ihre Vorzüge und Nachteile. Bei Primitiven wird z.B. der Speicher auf dem Stack erzeugt, bei Wrapper-Objekten wird vom Heap alloziiert und muss garbagecollected werden. Das heißt, wenn es z.B. auf Performance ankommt, nimmst du Primitive.

Ich mag Wrapper-Objekte sehr, da sie mir erlauben, primitiven Werten zwei Zustände zu geben: einmal, dass der Wert existiert und den Wert XYZ hat und einmal, dass der Wert unbekannt ist. Unsaubere Tricks wie "es ist unbekannt wenn der Wert < 0 ist" oder so entfallen auf ganz natürlich Weise. Auch muss man sich immer im Klaren sein, dass bei int a1 = 3, b1 = 3; und Integer a2 = 3, b2 = 3; a1 == b1 ist, aber nicht a2 == a3, da hier die Objektreferenzen verglichen werden - und die sind unterschiedlich.

Wieso das Konzept der Objektorientierung nicht 100% durchgezogen wurde, musst du mir nochmal im Detail erklären, damit ich dich vom Gegenteil überzeugen kann wink ich hoffe du spielst nicht auf die Mehrfachvererbung an, denn das ist das Machwerk Satans.

Last edited by HeelX; 01/18/13 12:04.