Java-Basics für Arbeit mit IDEs

1. Algorithmischer Ausgangspunkt eines Programms: Methode 'main(..)'

BlueJ versteckt das Verhalten "normaler" Java-Programme und stellt u.a. die Möglichkeiten zum interaktiven Aufruf von Methoden, Inspektion von Attributen etc. zur Verfügung.

Ein Java-Programm in "echten" IDEs muss hingegen (außer im Debugger) die vorgesehenen Mechanismen zum Ausführen implementieren.

Java hat (geerbt von der Programmiersprache C) eine fest vorgegebene Methode, bei der mit Programmstart die algorithmische Abarbeitung beginnt. Sie hat die Deklaration:

public static void main(String[] args)

Darin werden üblicherweise die ersten Objekte erzeugt, die dann die weitere Programmlogik enthalten. Mitunter werden auch weitere statische Methoden aufgerufen, in denen dann die Oblekte erzeugt werden.

Bei Programmen, die einfach eine definierte Aufgabe abarbeiten, kann der Programmfluss meist von hier verfolgt werden.

Bei Programmen, die wesentlich von Benutzer-Interaktionen gesteuert sind, wird die Nachverfolgung komplexer, da hier oft auf "Ereignisse" reagiert wird und Teile der Logik z.B. in GUI-Frameworks (GUI=Graph. User Interface) "versteckt" sind. Beispiele: JavaFX-Apps, Swing-Apps.

2. Statische Methoden (wie z.B. main(..))

Das Schlüsselwort static erzeugt eine Methode, die NICHT an ein Objekt gebunden ist, sondern an die Klasse. Damit kann sie zwar nicht auf Instanzvariable zugreifen (sie wurde ja nicht an einem konkreten Objekt aufgerufen, dessen Instanzvariablen damit zur Verfügung stünden), kann daher aber VOR der Existenz irgendeines Objekts aktiv werden – perfekt für den Start.

Wichtig zu wissen

Statische Methoden sind NICHT in der Vererbungslogik enthalten - sie müssen (von einer anderen Klasse aus) an ihrer eigenen Klasse aufgerufen werden.

Aufruf generell KlassenName.methodenName(), wobei KlassenName innerhalb der eigenen Klasse entfallen darf.

3. Packages

Bisher haben wir Packages nur für den Zugriff auf Klassen wie java.util.Scanner, etc. genutzt.

Packages sind aber ein integraler Teil (fast) jedes Klassennamens – so heißt die Klasse String eigentlich java.lang.String.

Package-Namen bestehen normalerweise aus mehreren, mit . getrennten Elementen. Auch der "nackte" Klassenname wird hinten nach einem weiteren Punkt angehängt.

Im Dateisystem werden die Packages als Verzeichnisse abgebildet. Es gibt jedoch KEINE echte Hierarchie – Sub-Packages haben keinerlei Bezug zu ihrem übergeordneten Package oder Funktionalitäten, die sie von diesen übernehmen würden.

Nur IDEs können oft Operationen durchführen, die diesen Eindruck erwecken (Umbenennen eines übergeordneten Package ändert auch den korrespondierendne Namensteil der Sub-Packages, etc.)

Eine übliche Benennungsstrategie ist das Beginnen mit der umgekehrten Domain der Organisation/Firma/Schule. Dahinter kommen Elemente der internen Organisationsstruktur und Projekt- bzw. Funktionalität. Ein mögliches Beispiel: at.spengergasse.rx2223_2xhif.Person.

Für Package-Namen gelten die selbem Regeln wie für andere Identifier – erstes Zeichen darf Buchstabe (groß/klein) oder '_' sein, danach sind auch Ziffern erlaubt.

  1. in Arbeit …​