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

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Generics, innere Klassen
10 Die Klassenbibliothek
11 Threads und nebenläufige Programmierung
12 Datenstrukturen und Algorithmen
13 Raum und Zeit
14 Dateien und Datenströme
15 Die eXtensible Markup Language (XML)
16 Grafische Oberflächen mit Swing
17 Grafikprogrammierung
18 Netzwerkprogrammierung
19 Verteilte Programmierung mit RMI und Web–Services
20 JavaServer Pages und Servlets
21 Applets
22 Midlets und die Java ME
23 Datenbankmanagement mit JDBC
24 Reflection und Annotationen
25 Logging und Monitoring
26 Sicherheitskonzepte
27 Java Native Interface (JNI)
28 Dienstprogramme für die Java-Umgebung
Stichwort

Download:
- ZIP, ca. 14,1 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel (8. Auflage) von Christian Ullenboom
Programmieren mit der Java Standard Edition Version 6
Buch: Java ist auch eine Insel (8. Auflage)

Java ist auch eine Insel (8. Aufl.)
8., aktual. Auflage, geb., mit DVD
1.475 S., 49,90 Euro
Galileo Computing
ISBN 978-3-8362-1371-4
Pfeil 3 Klassen und Objekte
Pfeil 3.1 Objektorientierte Programmierung
Pfeil 3.1.1 Warum überhaupt OOP?
Pfeil 3.1.2 Denk ich an Java, denk ich an Wiederverwendbarkeit
Pfeil 3.2 Eigenschaften einer Klasse
Pfeil 3.2.1 Die Klasse Point
Pfeil 3.3 Die UML (Unified Modeling Language)
Pfeil 3.3.1 Hintergrund und Geschichte zur UML
Pfeil 3.3.2 Wichtige Diagrammtypen der UML
Pfeil 3.3.3 UML-Werkzeuge
Pfeil 3.4 Neue Objekte erzeugen
Pfeil 3.4.1 Anlegen eines Exemplars einer Klasse mit dem new-Operator
Pfeil 3.4.2 Deklarieren von Referenzvariablen
Pfeil 3.4.3 Zugriff auf Variablen und Methoden mit dem ».«
Pfeil 3.4.4 Konstruktoren nutzen
Pfeil 3.5 Pakete und import-Deklarationen nutzen
Pfeil 3.5.1 Volle Qualifizierung und import-Deklaration
Pfeil 3.5.2 import *
Pfeil 3.6 Mit Referenzen arbeiten
Pfeil 3.6.1 Zuweisungen bei Referenzen
Pfeil 3.6.2 Methoden mit nicht-primitiven Parametern
Pfeil 3.7 Identität und Gleichheit
Pfeil 3.7.1 Identität von Objekten
Pfeil 3.7.2 Gleichheit und die Methode equals()
Pfeil 3.7.3 Die null-Referenz
Pfeil 3.8 Wrapper-Klassen und Autoboxing
Pfeil 3.8.1 Erzeugen von Wrapper-Objekten
Pfeil 3.8.2 Konvertierungen in eine String-Repräsentation
Pfeil 3.8.3 Die Klasse Integer
Pfeil 3.8.4 Die Klassen Double und Float für Fließkommazahlen
Pfeil 3.8.5 Die Basisklasse Number für numerische Wrapper-Objekte
Pfeil 3.8.6 Die Boolean-Klasse
Pfeil 3.8.7 Autoboxing: Boxing und Unboxing
Pfeil 3.9 Compilationseinheiten und eigene Pakete schnüren
Pfeil 3.9.1 Die package-Anweisung
Pfeil 3.9.2 Importieren von Klassen mit import
Pfeil 3.9.3 Hierarchische Strukturen und das Default-Package
Pfeil 3.9.4 Paketnamen
Pfeil 3.9.5 Klassen mit gleichen Namen in unterschiedlichen Paketen
Pfeil 3.9.6 Compilationseinheit (Compilation Unit)
Pfeil 3.9.7 Statischer Import
Pfeil 3.9.8 Eine Verzeichnisstruktur für eigene Projekte
Pfeil 3.10 Arrays
Pfeil 3.10.1 Deklaration von Arrays
Pfeil 3.10.2 Arrays mit Inhalt
Pfeil 3.10.3 Die Länge eines Arrays über das Attribut length
Pfeil 3.10.4 Zugriff auf die Elemente über den Index
Pfeil 3.10.5 Array-Objekte mit new erzeugen
Pfeil 3.10.6 Fehler bei Arrays
Pfeil 3.10.7 Die erweiterte for-Schleife
Pfeil 3.10.8 Arrays mit nicht-primitiven Elementen
Pfeil 3.10.9 Mehrdimensionale Arrays
Pfeil 3.10.10 Vorinitialisierte Arrays
Pfeil 3.10.11 Mehrere Rückgabewerte
Pfeil 3.10.12 Methode mit variabler Argumentanzahl (Vararg)
Pfeil 3.10.13 Klonen kann sich lohnen – Arrays vermehren
Pfeil 3.10.14 Feldinhalte kopieren
Pfeil 3.10.15 Die Klasse Arrays zum Vergleichen, Füllen und Suchen
Pfeil 3.11 Der Einstiegspunkt für das Laufzeitsystem: main()
Pfeil 3.11.1 Kommandozeilen-Argumente verarbeiten
Pfeil 3.11.2 Der Rückgabewert von main() und System.exit()
Pfeil 3.12 Zum Weiterlesen


Galileo Computing - Zum Seitenanfang

3.9 Compilationseinheiten und eigene Pakete schnüren Zur nächsten ÜberschriftZur vorigen Überschrift

Ein Java-Paket ist eine logische Gruppierung von Klassen. Zu einem Paket gehörende Klassen befinden sich normalerweise [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.] im gleichen Verzeichnis. Der Name des Pakets ist dann gleich dem Namen des Verzeichnisses (und natürlich umgekehrt). Nehmen wir folgende Verzeichnisstruktur mit einer Klasse an:

com/tutego/ com/tutego/Chocolate.java

Hier ist der Paketname com.tutego und somit der Verzeichnisname com/tutego/. Umlaute und Sonderzeichen sollten vermieden werden, da sie auf dem Dateisystem immer wieder für Ärger sorgen. Aber Bezeichner sollten ja sowieso immer auf Englisch sein.


Galileo Computing - Zum Seitenanfang

3.9.1 Die package-Anweisung Zur nächsten ÜberschriftZur vorigen Überschrift

Um die Klasse Chocolate in ein Paket com.tutego 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 com.tutego; 
 
public class Chocolate 
{ 
 ... 
}

Galileo Computing - Zum Seitenanfang

3.9.2 Importieren von Klassen mit import Zur nächsten ÜberschriftZur vorigen Überschrift

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

com.tutego.Chocolate s = new com.tutego.Chocolate();

Die praktischere Möglichkeit war, den Compiler über import auf die Klassen im Paket aufmerksam zu machen:

import com.tutego.Chocolate; 
 
class SantaClaus 
{ 
  Chocolate s;    // sonst com.tutego.Chocolate 
}

Damit nicht alle Klassen eines Pakets einzeln aufgeführt werden müssen, können wir auch mit dem Sternchen als einer Art Wildcard dem Compiler alle sichtbaren Klassen bekanntmachen:

import com.tutego.*;

Galileo Computing - Zum Seitenanfang

3.9.3 Hierarchische Strukturen und das Default-Package Zur nächsten ÜberschriftZur vorigen Überschrift

Pakete lassen sich in Hierarchien ordnen, sodass 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-Deklaration bezieht sich nur auf ein Verzeichnis und schließt die Unterverzeichnisse nicht mit ein.

Unbenanntes Paket (default package)

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

In Eclipse stehen Klassen im unbenannten Paket unter dem »virtuelles« (default package).

Abbildung 3.3 Das Verzeichnis »default package«


Galileo Computing - Zum Seitenanfang

3.9.4 Paketnamen Zur nächsten ÜberschriftZur vorigen Überschrift

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


Galileo Computing - Zum Seitenanfang

3.9.5 Klassen mit gleichen Namen in unterschiedlichen Paketen Zur nächsten ÜberschriftZur vorigen Überschrift

Ein Problem gibt es bei mehreren gleich benannten Klassen in unterschiedlichen Paketen. Hier ist eine volle Qualifizierung nötig. So gibt es in den Paketen 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 durcheinanderkommt, 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 - Zum Seitenanfang

3.9.6 Compilationseinheit (Compilation Unit) Zur nächsten ÜberschriftZur vorigen Überschrift

Die package- und import-Deklarationen gehören nicht wirklich zu der Typ-Deklaration, die nur ein class C { } oder verwandte Typdeklarationen umfasst. Genaugenommen sind dies alles Bestandteile einer Compilationseinheit (Compilation Unit). So besteht eine Compilationseinheit aus höchstens einer Paketdeklaration, beliebig vielen import-Deklarationen, und beliebig vielen Typdeklarationen. Ein Paket ist letztendlich eine Sammlung aus Compilationseinheiten.


Galileo Computing - Zum Seitenanfang

3.9.7 Statischer Import Zur nächsten ÜberschriftZur vorigen Überschrift

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 aufgeführt wird oder wenn 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.

Praktisch ist das zum Beispiel für die Bildschirmausgabe, wenn die statische Variable out aus System eingebunden wird:

import static java.lang.System.out;

Bei der sonst üblichen Ausgabe über System.out.printXXX() kann nach dem statischen Import der Klassenname entfallen, und es bleibt beim out.printXXX().

Listing 3.10 StaticImport.java

import static java.lang.System.out; 
import static javax.swing.JOptionPane.showInputDialog; 
import static java.lang.Integer.parseInt; 
import static java.lang.Math.max; 
import static java.lang.Math.min; 
 
class StaticImport 
{ 
  public static void main( String[] args ) 
  { 
    int i = parseInt( showInputDialog( "Erste Zahl " ) ); 
    int j = parseInt( showInputDialog( "Zweite Zahl " ) ); 
    out.printf( "%d ist größer oder gleich %d.%n", max(i, j), min(i, j)  ); 
  } 
}

Mehrere Typen statisch importieren

Das statische Import bindet im Beispiel die max() und min()-Funktionen ein. Besteht Bedarf für weitere Funktionen, gibt es neben der individuellen Aufzählung eine Wildcard:

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 eingebunden werden kann. Der Compiler interpretiert toString() als Aufruf einer Objektmethode. (Auch dann, wenn die aufrufende Methode selbst statisch ist.)



Galileo Computing - Zum Seitenanfang

3.9.8 Eine Verzeichnisstruktur für eigene Projekte topZur vorigen Überschrift

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 erzeugten 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 Anregungen zur Verzeichnisstruktur gibt die Webseite von Sun, http://java.sun.com/blueprints/code/projectconventions.html.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Java ist auch eine Insel





Java ist auch eine Insel
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Tipp
Zum Katalog: Coding for Fun





 Coding for Fun


 Buchempfehlungen
Zum Katalog: Objektorientierte Programmierung





 Objektorientierte
 Programmierung


Zum Katalog: Einstieg in Eclipse 3.4






 Einstieg in
 Eclipse 3.4


Zum Katalog: Java 6 lernen mit Eclipse






 Java 6 lernen
 mit Eclipse


Zum Katalog: NetBeans Platform 6






 NetBeans
 Platform 6


Zum Katalog: Java und XML






 Java und XML


Zum Katalog: Visual C# 2008






 Visual C# 2008


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


Zum Katalog: C++ von A bis Z






 C++ von A bis Z


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2009
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, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de