Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger

 << zurück
Java ist auch eine Insel von Christian Ullenboom
Programmieren für die Java 2-Plattform in der Version 5
Java ist auch eine Insel

Java ist auch eine Insel
5., akt. und erw. Auflage
1454 S., mit CD, 49,90 Euro
Galileo Computing
ISBN 3-89842-747-1
gp Kapitel 3 Klassen und Objekte
  gp 3.1 Objektorientierte Programmierung
    gp 3.1.1 Warum überhaupt OOP?
    gp 3.1.2 Wiederverwertbarkeit
  gp 3.2 Klassen benutzen
    gp 3.2.1 Die Klasse Point
  gp 3.3 Die UML (Unified Modeling Language)
    gp 3.3.1 Hintergrund und Geschichte zur UML
    gp 3.3.2 Wichtige Diagrammtypen der UML
  gp 3.4 Anlegen und Nutzen eines Punktes
    gp 3.4.1 Definieren von Referenz-Variablen
    gp 3.4.2 Anlegen eines Exemplars einer Klasse mit dem new-Operator
    gp 3.4.3 Zugriff auf Variablen und Methoden mit dem ».«
    gp 3.4.4 Konstruktoren nutzen
  gp 3.5 Import und Pakete
  gp 3.6 Die API-Dokumentation
  gp 3.7 Mit Referenzen arbeiten
    gp 3.7.1 Die null-Referenz
    gp 3.7.2 Zuweisungen bei Referenzen
    gp 3.7.3 Funktionen mit nichtprimitiven Parametern
    gp 3.7.4 Gleichheit von Objekten und die Methode equals()
  gp 3.8 Arrays
    gp 3.8.1 Deklaration von Arrays
    gp 3.8.2 Arrays mit Inhalt
    gp 3.8.3 Die Länge eines Arrays über das Attribut length
    gp 3.8.4 Zugriff auf die Elemente über den Index
    gp 3.8.5 Array-Objekte erzeugen
    gp 3.8.6 Fehler bei Arrays
    gp 3.8.7 Arrays mit nicht-primitiven Elementen
    gp 3.8.8 Vorinitialisierte Arrays
    gp 3.8.9 Die erweiterte for-Schleife
    gp 3.8.10 Mehrdimensionale Arrays
    gp 3.8.11 Die Wahrheit über die Array-Initialisierung
    gp 3.8.12 Mehrere Rückgabewerte
    gp 3.8.13 Argument per Referenz übergeben
    gp 3.8.14 Arrays klonen
    gp 3.8.15 Feldinhalte kopieren
    gp 3.8.16 Die Klasse Arrays zum Vergleichen, Füllen und Suchen
    gp 3.8.17 Methode mit variabler Argumentanzahl (vararg)
  gp 3.9 Der Einstiegspunkt für das Laufzeitsystem main()
    gp 3.9.1 Kommandozeilen-Parameter ausgeben
    gp 3.9.2 Der Rückgabewert von main() und System.exit()
    gp 3.9.3 Parser der Kommandozeilenargumente Apache CLI
  gp 3.10 Eigene Pakete schnüren
    gp 3.10.1 Die package-Anweisung
    gp 3.10.2 Importieren von Klassen mit import
    gp 3.10.3 Paketnamen
    gp 3.10.4 Hierarchische Strukturen und das Default-Package
    gp 3.10.5 Klassen mit gleichen Namen in unterschiedlichen Paketen
    gp 3.10.6 Statisches Import
    gp 3.10.7 Eine Verzeichnisstruktur für eigene Projekte


Galileo Computing

3.10 Eigene Pakete schnüredowntop

Ein Java-Paket ist eine logische Gruppierung von Klassen. Klassen, die zu einem Paket gehören, befinden sich normalerweise im gleichen Verzeichnis. Der Name des Pakets ist dann gleich dem Namen des Verzeichnisses (und natürlich umgekehrt). Nehmen wir folgende Verzeichnisstruktur an:

suessigkeiten/ suessigkeiten/Schokolade.java

Hier ist der Paketname (und somit Verzeichnisname) suessigkeiten. Umlaute sollten vermieden werden, da sie auf dem Dateisystem immer wieder für Ärger sorgen.


Galileo Computing

3.10.1 Die package-Anweisung  downtop

Um die Klasse Schokolade in ein Paket suessigkeiten zu setzen, enthält der Quellcode als oberstes eine package-Anweisung. Die package-Anweisung muss die erste Anweisung sein, sonst gibt es einen Übersetzungsfehler. Da Kommentare keine Anweisungen sind, lassen sich selbstverständlich Kommentare vor die package-Anweisung setzen.

package suessigkeiten;
public class Schokolade
{
 ...
}

Galileo Computing

3.10.2 Importieren von Klassen mit import  downtop

Um Klassen außerhalb des eigenen Paketes nutzen zu können, müssen sie dem Compiler präzise beschrieben werden. Die erste Möglichkeit war die volle Qualifizierung.

suessigkeiten.Schokolade s = new suessigkeiten.Schokolade();

Eine alternative und praktischere Möglichkeit ist, den Compiler in einer Klassendefinition mit import auf die Klassen im Paket aufmerksam zu machen.

import suessigkeiten.Schokolade;
class Weihnachtsmann
{
  Schokolade s;    // sonst suessigkeiten.Schokolade
}

Damit nicht alle Klassen eines Pakets einzeln aufgeführt werden müssen, lässt sich mit dem Sternchen als einer Art Wildcard auf alle sichtbaren Klassen zugreifen.

import suessigkeiten.*;

Das macht alle Typen aus dem Paket suessigkeiten dem Compiler bekannt.


Galileo Computing

3.10.3 Paketnamen  downtop

Prinzipiell kann ein Paketname beliebig sein, doch Hierarchien bestehen in der Regel aus umgedrehten Domänennamen. Aus der Domäne zur Webseite http://javatutor.de wird also de.javatutor. Diese Namensgebung gewährleistet, dass Klassen auch weltweit eindeutig bleiben. Ein Paketname wird in aller Regel komplett kleingeschrieben.

Die Paketnamen java, javax und sun

Sun hat für sich selbst einige Paketnamen reserviert, die von eigenen Klassen nicht genutzt werden sollen. So liegt unser java.awt.Point in einem Sun-Paket, und das ist leicht durch den Teil java zu erkennen. Wenn jemand eigene Klassen in Pakete mit dem Präfix java setzen würde, etwa java.ui, schafft er damit Verwirrung, da nicht mehr nachvollziehbar ist, ob das Paket bei jeder Distribution dabei ist (wie das bei den Sun-Klassen der Fall ist).


Galileo Computing

3.10.4 Hierarchische Strukturen und das Default-Package  downtop

Pakete lassen sich in Hierarchien ordnen, so dass in einem Paket wieder ein anderes Paket liegen kann; das ist genauso wie bei der Verzeichnisstruktur des Dateisystems. Sun definiert das Paket java für einen Hauptzweig, aber auch javax. Unter dem Paket java liegen dann zum Beispiel awt, util und weitere. Es werden durch import java.* nicht automatisch alle Klassen der Unterpakete mit eingebunden. Die import-Anweisung bezieht sich nur auf ein Verzeichnis und schließt die Unterverzeichnisse nicht mit ein.

Unbekanntes Paket (Default package)

Falls eine Klasse ohne Paket-Definition implementiert wird, so befindet sie sich standardmäßig im umbenannten Paket (engl. unnamed package), oder Default-Paket. Es ist eine gute Idee, eigene Klassen immer in Paketen zu organisieren. Das erlaubt auch feinere Sichtbarkeiten.

Abbildung
Hier klicken, um das Bild zu Vergrößern

Abbildung 3.6   Eclipse sieht für das unbekannte Paket ein »virtuelles« Verzeichnis vor. Es nennt sich »default package«.


Galileo Computing

3.10.5 Klassen mit gleichen Namen in unterschiedlichen Paketen  downtop

Ein Problem gibt es bei mehreren gleich benannten Klassen in unterschiedlichen Paketen. Hier ist eine volle Qualifizierung nötig. So gibt es im Paket java.awt und java.util eine Liste. Ein einfaches import java.awt.* und java.util.* hilft da nicht, weil der Compiler nicht weiß, ob die GUI-Komponente oder die Datenstruktur gemeint ist. Auch sagt ein import nichts darüber aus, ob die Klassen in der importierenden Datei jemals gebraucht werden. Das Gleiche gilt für die Klasse Date, die einmal in java.util und einmal in java.sql zu finden ist. Lustigerweise erweitert java.sql.Date die Klasse java.util.Date. Dass der Compiler hier nicht durcheinander kommt, ist ganz einfach dadurch zu erklären, dass er die Klassen nicht nur anhand ihres Namens unterscheidet, sondern vielmehr auch anhand ihrer Pakete. Der Compiler betrachtet intern immer eine volle Qualifizierung.


Galileo Computing

3.10.6 Statisches Import  downtop

Das import hat in Java die Bedeutung, den Compiler über die Pakete zu informieren, sodass eine Klasse nicht mehr voll qualifiziert werden muss, wenn sie im import-Teil explizit oder das Paket der Klasse genannt ist.

Falls eine Klasse statische Funktionen oder Konstanten vorschreibt, werden ihre Eigenschaften immer über den Klassennamen angesprochen. Es gibt nun mit dem statischen Import die Möglichkeit, die Klasseneigenschaften wie eigene Funktionen oder Variablen ohne Klassennamen sofort zu nutzen. Nehmen wir an, wir wollten das Maximum dreier Ganzzahlen a, b, c bestimmen. Wir würden das etwa so lösen können:

static int max( int aint bint c )
{
  return Math.max( aMath.max(bc) );
}

Über das statische Import kann die Funktion max() aus Math »importiert« werden, sodass der Klassenname entfallen kann. (Dass es mehrere überladene Varianten von max() gibt, ist kein Problem.)

import _saito_fett_  static _saito_fettout_  java.lang.Math.max;
class StatischesImport
{
  static int max( int aint bint c )
  {
    return max( amax(bc) );
  }
}

Das statische Import bindet jetzt aber nur die max()-Funktion ein. Besteht Bedarf für die min()-Funktion, gibt es zwei Möglichkeiten: Zum einen lässt sich ein zweites statisches Import nachschieben oder gleich alles aus der Math-Klasse statisch importieren:

import static java.lang.Math.*;

Auch wenn Java seit Version 5 diese Möglichkeit bietet, sollte der Einsatz maßvoll erfolgen. Die Möglichkeit der statischen Importe wird dann nützlicher, wenn Klassen Konstanten nutzen wollen. Doch dazu später mehr.


Hinweis   Eine Objektmethode aus der eigenen Klasse überdeckt statische importierte Methoden, was im Fall der toString()-Methode auffällt, die statisch aus der Utility-Klasse Arrays definiert wird. Der Compiler interpretiert toString() als Auruf einer Objektmethode. (Auch dann, wenn die aufrufende Methode selbst statisch ist.)


Galileo Computing

3.10.7 Eine Verzeichnisstruktur für eigene Projekte  toptop

Neben der Einteilung in Pakete für das eigene Programm ist es auch sinnvoll, die gesamte Applikation in verschiedenen Verzeichnissen aufzubauen. Im Allgemeinen finden sich drei wichtige Hauptverzeichnisse: src für die Quellen, lib für externe Bibliotheken, auf die das Programm aufbaut, und bin (oder build) für die erzeugen Klassen-Dateien. Das Verzeichnis src lässt sich noch weiter unterteilen, etwa für Quellen, die Testfälle implementieren, oder für Beispiele:

src/   core/   examples/   test/ lib/ bin/

Mehr zu diesem Thema unter http://java.sun.com/blueprints/code/projectconventions.html.




1  Ich schreibe »normalerweise«, da die Paketstruktur nicht zwingend auf Verzeichnisse abgebildet werden muss. Pakete könnten beispielsweise vom Klassenlader aus einer Datenbank gelesen werden. Im Folgenden wollen wir aber immer von Verzeichnissen ausgehen.

 << zurück




Copyright © Galileo Press GmbH 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de