Kurs Diskussion:Java – ein schneller Einstieg/Rechnen mit eingegebenen Zahlen

Properties

im Abschnitt Objekte mit Eigenschaften stehen die Behauptungen:

• Objekte übergeben Properties mit Methoden der Form getDasDa().
• Objekte erhalten Properties mit Methoden der Form setDasDa().

Ich halte diese Formulierung für unglücklich, denn

• "Properties" stellen ja eine eigenständige Java-Klasse dar
• Methoden der Art "getDasDa()" liefern im Allgemeinen irgendwelche Objekte oder primitive Typen
• Methoden der Art "setDasDa()" beeinflussen im Allgemeinen das Verhalten bzw. die Eigenschaften eines Objekts (auch ohne jedesmal irgendetwas an das Objekt übergeben zu müssen).

Ich finde folgende Formulierung eventuell verständlicher:

• mit Methoden der Form getDasDa() erhält man Auskunft über Eigenschaften von Objekten.
• mit Methoden der Form setDasDa() beeinflusst man die Eigenschaften von Objekten.

--Exxu 09:55, 27. Sep. 2007 (CEST)

Hallo Exxu, die Antworten sind etwas umfangreicher ausgefallen.

• Zu Punkt-1:

Ein "property" ist eine Eigenschaft. Die von Dir angeführte Klasse "Properties" wird normalerweise zur Internationalisierung in Abhängigkeit der Länderkennung benutzt. Da werden die Resources aus "???.properties"-Dateien geladen und die über Namen assoziierten Werte (meist Texte) entweder in den Attributen von Methoden oder direkt in die entsprechenden fields gespeichert. Danach hat jedes property des Objekts die entsprechenden Werte, genau so als wenn sie im Quelltext zugewiesen würden.

Die IDEs (eclipse, NetBeans) bieten eine Separation von Texten aus dem Code und Unterbringung in einer Properties-Datei an. Allerdings würde eine Besprechung dieser Möglichkeiten zu weit führen und dem Titel des Kurses widersprechen.

• Zu Punkt-2:

Die Vermutung, dass get-Methoden normalerweise "primitive" Typen liefern ist schlicht falsch. Das macht die Methode object.getClass(). Es gibt in Java zwar primitive types. Dabei handelte es sich ursprünglich (noch bis jdk1.0.2_x) um Klassen, die nicht erweiterbar sind. Dann sind es nämlich Typen. Abstarkte Klassen gab es damals noch nicht. Die Bezeichnung primitive wird heute für die byte, short, int, long, float double und char benutzt. Diese Klassen können weder mit einem Creator (auch nicht der default-Creator) instanziert noch erweitert werden.

• Zu Punkt-3:

Die "properties", für die sog. "getter"- und "setter"-Methoden vorhanden sind, verkörpern stets Eigenschaften des Objekts. Sie können sogar als statisch deklariert sein, dann sind es Eigenschaften der Klasse. Weil aber jede Klasse auch Objekt ist (ohne Gödel zu ignorieren - siehe core Java Bd 1 u.2) ist das die allgemeine Attributierung. In Java gilt allgemein, dass ein klassenweit deklariertes field (Pascal: globale Variable) als property bezeichnet wird. Abhängig von den Attributen private und ggf. protected müssen für einen Datenaustausch mit Instanzen anderer Klassen oder Instanzen aus anderen packages Methoden vorhanden sein. Eben die erwähnten get- und set-Methoden. Eine klassenweite Deklaration von fields mit rein objektinternen Aufgaben ist sehr schlechter Programmierstil.

Jede, absolut jede Änderung des Verhaltens oder der Eigenschaften eines Objekts beruht auf der Änderung der Inhalte von Variablen. Es spielt keine Rolle, ob die Dinger fields heissen oder nicht. Es spielt auch keine Rolle , ob die veränderten Variablen lokal, global (klassenweit) existieren. Irgendwo, in irgend einer "Abstammungsklasse" ist ein Variableninhalt verändert worden.

Soviel zum Allgemeinen. Dein Vorschlag

...setDasDa() beeinflusst ... Eigenschaften ...

ist einfach, prägnant wird eingebaut. Der Vorschlag

...getDasDa() (gibt) Auskunft über Eigenschaften

ist nicht präzise genug. Es kann durchaus sein, dass es sich bei dem property (field) um eine Referenz handelt. Damit kann es sich also auch um eine Methode handeln (Reflection Classes). Eine Methode ist nun gewiss keine "Auskunft", sehr wohl aber eine Eigenschaft. Ganz allgemein besteht das Problem darin, ob eine get-Methode einen Wert, eine Referenz oder ein neues Objekt (mit sog. factories) übergibt.

Die enge Verwandschaft von property, Attribut, Eigenschaft und der Unterschied zur Klasse "Properties" müsste doch wohl nur verdeutlicht werden; wenn die Klasse auch besprochen würde. --Heuerli 14:58, 29. Sep. 2007 (CEST)

Groß- und Kleingeschriebenes

Im Abschnitt Unterschiede zwischen groß- und kleingeschriebenen "Typen" wird mit String-Werten hantiert, um letztendlich mit ihnen rechnen zu können.

Warum aber wird dort folgendes getan?

String betragText = "1234.56";
String rabattText = "7";
Float betragZahl = new Float( betragText);
Float rabattZahl = new Float( rabattText);
float betragWert = betragZahl.floatValue();
float rabattWert = rabattZahl.floatValue();

Ginge es nicht auch mit etwas weniger Schreibaufwand in folgender Weise?:

String betragText = "1234.56";
String rabattText = "7";
float betragWert = Float.parseFloat( betragText );
float rabattWert = Float.parseFloat( rabattText );

--Exxu 10:41, 27. Sep. 2007 (CEST)

Hallo Exxu, natürlich geht es kürzer - sogar erheblich. Die Verkürzung dieser Deklarationssequenz ist ja eines der Ziele in diesem Kurs. In den weiteren Abschnitten wirst Du zweifellos fündig. --Heuerli 14:58, 29. Sep. 2007 (CEST)

Argumentenliste

Im Abschnitt Ausgabe über System-Streams ist die Rede von einer Argumentenliste. Zitat:

"Dem Compiler kommt es übrigens nur auf das Vorhandensein eines Strings in der Argumentliste an, was bedeutet, dass diese nicht unbedingt mit einem String beginnen muss.".

Da aber die Methode "println" nur ein einziges Argument (und keine Argumentenliste) kennt, scheint mir die verwendete Bezeichnung irreführend. --Exxu 10:25, 27. Sep. 2007 (CEST)

Hallo Exxu. In Java hat ausnahmslos jede Methode eine Argumentliste. Ebenso wie in C/C++. Das ist also nicht irreführend, sondern einfach eine Tatsache. So wie es in der Mathematik die leere Menge gibt, so gibt es in der Informatik leere Listen.

Motiv ist die gemeinsame Unterbingung von Argumenten, Parametern und lokaler Variablen in einem für die Methode individuellen Speicherbereich mit Stack-Organisation. Diese Vorgehensweise basiert auf der alten "p-code"-Maschine. Wenn eine Methode keine Argumente hat, dann hat sie trotzdem eine Argumentliste. Die hat dann die Länge 0, hat sie nur ein Argument, so hat die Liste die Länge 1 usw. In jedem Fall muss der verarbeitenden Maschine (physisch oder virtuell) die Länge der Liste bekannt sein. --Heuerli 14:58, 29. Sep. 2007 (CEST)