Kurs:Java – ein schneller Einstieg/Projekt beenden

• Einleitung
• Grundlagen
• Rechnen
• GUI
• Events
• Frames
• Usability
• Exceptions
•  Javadoc  
• Anhang

Projekt beenden

Die gestellte Aufgabe ist gelöst. Das Projekt muss nun noch abgeschlossen werden. Dabei ist nun nicht mehr der Kunde wichtig, sondern das Team. Es ist sehr unwahrscheinlich, dass so eine kleine Anwendung eigenständig ist. Eigentlich sollten Anwendungen stets so angelegt werden, dass sie auch für andere nutzbar sind.

Hier muss also noch einiges getan werden. Niemand kann an die Daten, es fehlt eine Dokumentation und die Kommentare sind auch nicht einheitlich. Das mag an Bürokratie oder Detailbesessenheit erinnern, aber die API-Doc war zweifellos sehr nützlich. Sie ist nur dadurch zustande gekommen, weil diese letzten Punkte berücksichtigt wurden.

Ergebnisse publizieren

Für das Programmierteam wäre es wahrscheinlich angenehm, die ermittelten Ergebnisse nicht immer ablesen zu müssen, um sie in das Gesamtsystem zu übernehmen. Deshalb sollten ein paar get-Methoden in dieser Klasse vorhanden sein. Es drängt sich förmlich auf, die bereits erstellten setBetrag(...) und setRabatt(...) Methoden in entsprechende gets umzuwandeln. Jedoch wäre das nicht konsequent.

Noch einmal zurück zu den Überlegungen hinsichtlich Manipulation der Daten. Echte Konsistenz liegt nur unmittelbar nach dem Klick auf die Schaltfläche "berechnen" vor. Danach kann jedes der beiden Eingabefelder erneut beschrieben werden, was zu völlig sinnlosen Daten führt, wenn die Inhalte der Felder zu diesem Zeitpunkt gelesen werden. Es muss demnach sichergestellt sein, dass die get-Methoden nur korrekte oder keine Daten übermitteln. Erneutes Überdenken der Konzeption ist also erforderlich.

Die gesamte GUI ist nur ein Hilfsmittel für den Anwender. Sie hat mit den Daten prinzipiell nichts zu tun, sondern dient nur deren Sichtbarmachung. Wenn dieser Schritt getan ist, ist die weitere Vorgehensweise sehr einfach. Die Daten sind Properties, die GUI ist methodisch. Im vorhandenen Programm sind als Properties nur die TextFields vorhanden, aus denen ja die Daten erst extrahiert oder in denen sie angezeigt wurden.

Properties sind Privatangelegenheiten

Zunächst werden die Schnittstellen definiert. Interessant sind ausschließlich die ermittelten Werte, weshalb die „get“-Methoden ausnahmslos den primitiven Typ „float“ übergeben. Es fehlen noch die Properties, die sogleich als Variablen vom Typ float und einem begrenzten view namens private erstellt werden.

 private float betrag = 0;
 private float rabatt = 0;
 private float result = 0;
 
  public float getBetrag() {
   return betrag;
  }
  public float getRabatt() {
   return rabatt;
  }
  public float getResult() {
   return result;
  }

Diese Methoden wurden bereits ganz am Anfang erwähnt. Moderne IDEs fragen bei der Verwendung des Attributs „private“ nach der automatischen Erzeugung der entsprechenden „get“- und „set“-Methoden.

Berechnen darf jeder, das Ergebnis geht niemanden etwas an

Wann müssen die Werte in die Variablen eingetragen werden? Weil die Korrektheit nur unmittelbar nach der Berechnung gewährleistet ist, sollten die Werte auch zu diesem Zeitpunkt in den Variablen abgelegt werden. Damit ändert sich die Methode calculate() und die Anweisung der Ergebnisausgabe.

private void calculate() {
 betrag = valueOf( betragFeld.getText());
 rabatt = valueOf( rabattFeld.getText());
 result = betrag * (1 - rabatt / 100);
}

Die lokalen Variablen sind überflüssig, sie werden einfach durch die privaten Properties ersetzt. Nun noch die Änderung der Ergebnisausgabe. Aus der Anweisung

ausgabeFeld.setText( ""+calculate());

muss der Aufruf von calculate() zunächst herausgenommen werden, denn die neue Methode übergibt keinen Wert mehr. Der Aufruf wird durch die Variable <codee>result ersetzt, womit sich die neue Ausgabeanweisung ändert zu

calculate();
ausgabeFeld.setText( ""+result);

Die Datei "RabattPanel14.java" enthält nun auch diese Änderungen und außerdem die „get“-Methoden. Es könnte noch viel an diesem kleinen Programm gearbeitet werden, aber es soll ja nur als Sprungbrett für den eigentlichen Einstieg in Java dienen.

Abschließen eines Projekts

Die Datenkonsistenz ist gesichert, eventuelle "Manipulationen" in der Anzeige werden nicht publiziert, kurzum – "Alles steht zum Besten in der besten aller denkbaren Welten." (Blaise Pascal). Aber es nagen Zweifel: Ist der Quelltext auch nach 1 bis 2 Jahren noch einleuchtend? Wie war das noch mit den uneditierbaren Textfeldern im alten JDK? Wie und wo könnte Dies oder Das oder was...

Es fehlt eine Dokumentation!

Kommentierung, Dokumentation

Es fehlt die Kommentierung und die elementare Dokumentation. Kommentare sind in Java die erste Voraussetzung für eine durchgehend einheitliche Dokumentation. So kennt Java gleich drei verschiedene Formen der Kommentareinleitung, die sich wieder in zwei funktionelle Kategorien unterteilen lassen.

//

ist die einfachste Form und besagt weiter nichts als: Ignoriere alle Zeichen bis zum Zeilenende.

/*

bietet die Möglichkeit durchgehende Kommentierungstexte über mehrere Zeilen einzufügen. Es besagt: Ignoriere alle Zeichen bis */ einschließlich.

/**

ist die Einleitung eines Kommentars, der in die Dokumentation übernommen wird. Es bedeutet wieder: Ignoriere alle Zeichen bis */ einschließlich. Der Text dieser Kommentare wird von "javadoc", dem Hilfsprogramm zur Dokumentation, übernommen.

Einsatz von javadoc

Die Dokumentation wird von Java durch ein Hilfsmittel in einer bisher kaum dagewesenen Form erleichtert. Die Möglichkeiten sind äußerst vielfältig und deshalb wird hier nur der Einsatz der „Standard Doclet“ beschrieben. Detaillierte Informationen über die Verwendung von „javadoc“ sind in der Java-Dokumentation (da wo auch die API-Dokumentation ist) unter dem Verzeichnis „tooldocs“ zu finden.

Der erste Kontakt mit diesem Werkzeug kann durch Eingabe auf der Kommandozeile durch

javadoc -d doku -private RabattPanel14

hergestellt werden. Natürlich muss vorher in das Verzeichnis mit den zu dokumentierenden Dateien gewechselt werden. Die Elemente dieser Zeile sind

javadoc

das Programm zur Erzeugung von Dokumentationen.

-d

eine Option, um die folgende nicht leere Zeichenkette als Pfadangabe für die Dokumentationsdateien zu erklären.

doku

der relative (es kann auch ein absoluter sein) Pfad, in dem die erzeugten Dateien abgelegt werden.

-private

eine Option, um alle (also auch die privaten) Definitionen (Properties und Methoden) in die Dokumentation aufzunehmen.

RabattPanel14

die zu dokumentierende(n) Datei(en). Hier sind auch Angaben wie "*.*" (das sind alle Dateien im aktuellen Pfad) usw. möglich.

Das Ergebnis dieses Aufrufs mag begeistern, aber es besteht praktisch nur aus einer Auflistung aller vorhandenen Properties und Methoden. Der beschreibende Inhalt fehlt. Wie dieser beschreibende Inhalt in den Quellcode integriert wird und wie er gleichzeitig dem Programmierer Hinweise gibt, ohne dass Letzterer den Kommentar komplett lesen muss, wird hier kurz erörtert.

Übernahme veralteter Kommentierungsstyles

Jeder Betrieb, jedes Unternehmen hat seine Eigenheiten. Dazu zählen auch Kommentierungsstyles. Um „javadoc“ zu nutzen, ist es unabdingbar geworden die beschriebenen Elemente in den Quelltext einzubinden. Dabei gehen manch alte Gewohnheiten "über Bord". Geschickte Anwendung der gebotenen Möglichkeiten gestatten jedoch oft, die Kommentierungen der "Altvorderen" zu übernehmen.

Hier einige "gängige" Kommentarformen aus alten Quelltexten:

/*--------------------*/
/* Sequenz / Schleife */
/*--------------------*/

Dieser Kommentar über einem Abschnitt aus mehreren Zeilen wird vorzugsweise bei Schleifen, und Fallunterscheidungen eingesetzt.

//*============================*/
/** Private / Protected Method */
//*============================*/

Dieser Art von Kommentar zu wird gern zu „Unterprogrammen“ mit eingeschränkter Sichtbarkeit verwendet, also bei lokalen Funktionen oder Prozeduren. Dies ist in Pascal sehr verbreitet.

//*****************/
/** Public Method */
//*****************/

Dieser Kommentar zu „Unterprogrammen“ mit uneingeschränkter Sichtbarkeit wird häufig für globale Funktionen oder Prozeduren eingesetzt.

Beispiel für moderne Kommentare

Kommentare der "/**"-Form, die unterhalb der Klassendefinitionsebene (z.B. innerhalb von Methoden) liegen, bleiben von javadoc unberührt. Sie entsprechen dann den einfachen, nicht dokumentierenden Kommentaren. In den gängigen Beispielen von Javaprogrammen werden keine Unterschiede zwischen den views gemacht. Auch die einschlägigen IDEs machen keine derartigen Unterscheidungen. Die Vorgaben der IDEs können jedoch problemlos erweitert werden. Ein "normaler" Kommentar für die Dokumentation hat die Form:

/**
  * Das hier ist die ultimative Methode für
  * Internetverbindungen.
  *
  * params:
  * URL url: die Internetadresse
  * int count: der Verbindungszähler
*/

Wie das bisherige Programm durch Kommentare sinnvoll ergänzt werden kann, zeigt die Datei "RabattPanel15.java". Die Anwendung von javadoc auf dieses kommentierte Programm sind im Ordner docjav abgelegt und kann dort index.html. angesehen werden. Es zeigt sich schnell, dass eine vollständige Dokumentation des Quelltextes mit diesem Werkzeug möglich ist, sofern die Kommentare mehrzeilig sind und Angaben über Argumente und Rückgabewerte enthalten. Die o.a.Form der "uralt-Kommentierung" ist somit eigentlich hinfällig, es sei denn die "Firmenphilosophie" verlangt es (Als Java-Spezialist hat man die tollsten Gründe den Arbeitgeber zu wechseln).

Resümee

Eine kurze Zusammenfassung des bisher Erreichten:

• Unterschiede zwischen den Begriffen von Zeichenfolge, Zahl und Wert.
• Notwendigkeit von Typen, Bezeichnern und Referenzen.
• Einsatz von Creator-Methoden zur Umwandlung von Zeichenketten in Zahlenobjekte.
• Definition einer Klasse und der Einsatz der main-Methode.
• Aufbau einer GUI mit Frame, TextFields.
• Konzept der EventListener in Form des WindowAdapters.
• Aufteilung von Projekten in mehere Klassen und Optimierung durch den Einsatz eigener Methoden..
• Das view (Sichtbarkeit von außen) in Form von public und private.
• Unterschiede zwischen Variablen und Properties.
• Optimierung durch Anwendung von Substitutionen und elementarer Mathematik.
• Einsatz von LayoutManagern und die Kapselung von Komponenten in Container.
• Anwendung externer und interner EventListener durch den Einsatz des ActionListeners.
• Ausnahmebehandlung und Anwendung eines eigenen ExceptionHandlers.
• Äderung von Properties vorhandener Objekte zum Zwecke der Fehlerbehandlung.
• Focussierung bestimmter Komponenten.
• Elementare Schutzvorrichtungen vor Datenmanipulation.
• Kommentierung Dokumentation von Java-Programmen mit javadoc.

Wer hätte gedacht, in so kurzer Zeit so viel über eine Programmiersprache zu lernen? Die abschreckenden Bemerkungen zu Beginn sind nicht mehr so abschreckend, die Suche nach Methoden in der API-Dokumentation wird immer häufiger zu einer Bestätigung der vermuteten Schreibweise. Objekte haben ihre Abstraktheit weitgehend eingebüßt und werden behandelt, wie andere Referenzen auch. Einem tieferen Einstieg in die Programmierung mit Java steht nichts mehr im Weg.