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

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Exceptions
7 Äußere.innere Klassen
8 Besondere Klassen der Java SE
9 Generics<T>
10 Architektur, Design und angewandte Objektorientierung
11 Die Klassenbibliothek
12 Einführung in die nebenläufige Programmierung
13 Einführung in Datenstrukturen und Algorithmen
14 Einführung in grafische Oberflächen
15 Einführung in Dateien und Datenströme
16 Einführung in die <XML>-Verarbeitung mit Java
17 Einführung ins Datenbankmanagement mit JDBC
18 Bits und Bytes und Mathematisches
19 Die Werkzeuge des JDK
A Die Klassenbibliothek
Stichwort

Download:
- Aufgaben, ca. 1,1 MB
- Programme, ca. 12,8 MB

Buch bestellen
Ihre Meinung?

Spacer
Java ist auch eine Insel von Christian Ullenboom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
Galileo Computing
1308 S., 10., aktualisierte Auflage, geb., mit DVD
ca. 49,90 Euro, ISBN 978-3-8362-1802-3
Pfeil 5 Eigene Klassen schreiben
Pfeil 5.1 Eigene Klassen mit Eigenschaften deklarieren
Pfeil 5.1.1 Attribute deklarieren
Pfeil 5.1.2 Methoden deklarieren
Pfeil 5.1.3 Die this-Referenz
Pfeil 5.2 Privatsphäre und Sichtbarkeit
Pfeil 5.2.1 Für die Öffentlichkeit: public
Pfeil 5.2.2 Kein Public Viewing – Passwörter sind privat
Pfeil 5.2.3 Wieso nicht freie Methoden und Variablen für alle?
Pfeil 5.2.4 Privat ist nicht ganz privat: Es kommt darauf an, wer’s sieht *
Pfeil 5.2.5 Zugriffsmethoden für Attribute deklarieren
Pfeil 5.2.6 Setter und Getter nach der JavaBeans-Spezifikation
Pfeil 5.2.7 Paketsichtbar
Pfeil 5.2.8 Zusammenfassung zur Sichtbarkeit
Pfeil 5.3 Statische Methoden und statische Attribute
Pfeil 5.3.1 Warum statische Eigenschaften sinnvoll sind
Pfeil 5.3.2 Statische Eigenschaften mit static
Pfeil 5.3.3 Statische Eigenschaften über Referenzen nutzen? *
Pfeil 5.3.4 Warum die Groß- und Kleinschreibung wichtig ist *
Pfeil 5.3.5 Statische Variablen zum Datenaustausch *
Pfeil 5.3.6 Statische Eigenschaften und Objekteigenschaften *
Pfeil 5.4 Konstanten und Aufzählungen
Pfeil 5.4.1 Konstanten über öffentliche statische finale Variablen
Pfeil 5.4.2 Typ(un)sichere Aufzählungen *
Pfeil 5.4.3 Aufzählungen mit enum
Pfeil 5.5 Objekte anlegen und zerstören
Pfeil 5.5.1 Konstruktoren schreiben
Pfeil 5.5.2 Der vorgegebene Konstruktor (default constructor)
Pfeil 5.5.3 Parametrisierte und überladene Konstruktoren
Pfeil 5.5.4 Copy-Konstruktor
Pfeil 5.5.5 Einen anderen Konstruktor der gleichen Klasse mit this() aufrufen
Pfeil 5.5.6 Ihr fehlt uns nicht – der Garbage-Collector
Pfeil 5.5.7 Private Konstruktoren, Utility-Klassen, Singleton, Fabriken
Pfeil 5.6 Klassen- und Objektinitialisierung *
Pfeil 5.6.1 Initialisierung von Objektvariablen
Pfeil 5.6.2 Statische Blöcke als Klasseninitialisierer
Pfeil 5.6.3 Initialisierung von Klassenvariablen
Pfeil 5.6.4 Eincompilierte Belegungen der Klassenvariablen
Pfeil 5.6.5 Exemplarinitialisierer (Instanzinitialisierer)
Pfeil 5.6.6 Finale Werte im Konstruktor und in statischen Blöcken setzen
Pfeil 5.7 Assoziationen zwischen Objekten
Pfeil 5.7.1 Unidirektionale 1:1-Beziehung
Pfeil 5.7.2 Bidirektionale 1:1-Beziehungen
Pfeil 5.7.3 Unidirektionale 1:n-Beziehung
Pfeil 5.8 Vererbung
Pfeil 5.8.1 Vererbung in Java
Pfeil 5.8.2 Spielobjekte modellieren
Pfeil 5.8.3 Die implizite Basisklasse java.lang.Object
Pfeil 5.8.4 Einfach- und Mehrfachvererbung *
Pfeil 5.8.5 Die Sichtbarkeit protected
Pfeil 5.8.6 Konstruktoren in der Vererbung und super()
Pfeil 5.9 Typen in Hierarchien
Pfeil 5.9.1 Automatische und explizite Typanpassung
Pfeil 5.9.2 Das Substitutionsprinzip
Pfeil 5.9.3 Typen mit dem instanceof-Operator testen
Pfeil 5.10 Methoden überschreiben
Pfeil 5.10.1 Methoden in Unterklassen mit neuem Verhalten ausstatten
Pfeil 5.10.2 Mit super an die Eltern
Pfeil 5.10.3 Finale Klassen und finale Methoden
Pfeil 5.10.4 Kovariante Rückgabetypen
Pfeil 5.10.5 Array-Typen und Kovarianz *
Pfeil 5.11 Drum prüfe, wer sich ewig dynamisch bindet
Pfeil 5.11.1 Gebunden an toString()
Pfeil 5.11.2 Implementierung von System.out.println(Object)
Pfeil 5.11.3 Nicht dynamisch gebunden bei privaten, statischen und finalen Methoden
Pfeil 5.11.4 Dynamisch gebunden auch bei Konstruktoraufrufen *
Pfeil 5.11.5 Eine letzte Spielerei mit Javas dynamischer Bindung und überschatteten Attributen *
Pfeil 5.12 Abstrakte Klassen und abstrakte Methoden
Pfeil 5.12.1 Abstrakte Klassen
Pfeil 5.12.2 Abstrakte Methoden
Pfeil 5.13 Schnittstellen
Pfeil 5.13.1 Schnittstellen deklarieren
Pfeil 5.13.2 Implementieren von Schnittstellen
Pfeil 5.13.3 Markierungsschnittstellen *
Pfeil 5.13.4 Ein Polymorphie-Beispiel mit Schnittstellen
Pfeil 5.13.5 Die Mehrfachvererbung bei Schnittstellen *
Pfeil 5.13.6 Keine Kollisionsgefahr bei Mehrfachvererbung *
Pfeil 5.13.7 Erweitern von Interfaces – Subinterfaces
Pfeil 5.13.8 Konstantendeklarationen bei Schnittstellen
Pfeil 5.13.9 Initialisierung von Schnittstellenkonstanten *
Pfeil 5.13.10 Abstrakte Klassen und Schnittstellen im Vergleich
Pfeil 5.14 Zum Weiterlesen

Rheinwerk Computing - Zum Seitenanfang

5.11 Drum prüfe, wer sich ewig dynamisch bindetZur nächsten Überschrift

Bei der Vererbung haben wir eine Form der Ist-eine-Art-von-Beziehung, sodass die Unterklassen immer auch vom Typ der Oberklassen sind. Die sichtbaren Methoden, die die Oberklassen besitzen, existieren somit auch in den Unterklassen. Der Vorteil bei der Spezialisierung ist, dass die Oberklasse eine einfache Implementierung vorgeben und eine Unterklasse diese überschreiben kann. Wir hatten das bisher bei toString() gesehen. Doch nicht nur die Spezialisierung ist aus Sicht des Designs interessant, sondern auch die Bedeutung der Vererbung. Bietet eine Oberklasse eine sichtbare Methode an, so wissen wir immer, dass alle Unterklassen diese Methode haben werden, egal, ob sie die Methode überschreiben oder nicht. Wir werden gleich sehen, dass dies zu einem der wichtigsten Konstrukte in objektorientierten Programmiersprachen führt.


Rheinwerk Computing - Zum Seitenanfang

5.11.1 Gebunden an toString()Zur nächsten ÜberschriftZur vorigen Überschrift

Da jede Klasse Eigenschaften von java.lang.Object erbt, lässt sich auf jedem Objekt die toString()-Methode aufrufen. Sie soll in unseren Klassen GameObject und Room wie folgt implementiert sein:

Listing 5.80: com/tutego/insel/game/vf/GameObject.java, GameObject

public class GameObject
{
public String name;

@Override public String toString()
{
return String.format( "GameObject[name=%s]", name );
}
}

Listing 5.81: com/tutego/insel/game/vf/Room.java, Room

public class Room extends GameObject
{
public int size;

@Override public String toString()
{
return String.format( "Room[name=%s, size=%d]", name, size );
}
}

Die Unterklassen GameObject und Room überschreiben die toString()-Methode aus Object. Bei einem toString() auf einem GameObject kommt nur der Name in die toString()-Kennung, und bei einem toString() auf einem Room-Objekt kommen Name und Größe in die String-Repräsentation.

Es fehlen noch einige kleine Testzeilen, die drei Räume aufbauen. Alle rufen die toString()-Methoden auf den Räumen auf, wobei der Unterschied darin besteht, dass die verweisende Referenzvariable alle Typen von Room durchgeht: Ein Room ist ein Room, ein Room ist ein GameObject, und ein Room ist ein Object:

Listing 5.82: com/tutego/insel/game/vf/Playground.java, main()

Room rr = new Room();
rr.name = "Affenhausen";
rr.size = 7349944;
System.out.println( rr.toString() );

GameObject rg = new Room();

rg.name = "Affenhausen";
System.out.println( rg.toString() );

Object ro = new Room()
;
System.out.println( ro.toString() );

Jetzt ist die spannendste Frage in der gesamten Objektorientierung folgende: Was passiert bei dem Methodenaufruf toString()?

Room[name=Affenhausen, size=7349944]
Room[name=Affenhausen, size=0]
Room[name=null, size=0]

Die Ausgabe ist leicht zu verstehen, wenn wir berücksichtigen, dass der Compiler nicht die gleiche Weisheit besitzt wie die Laufzeitumgebung. Vom Compiler würden wir erwarten, dass er jeweils das toString() in Room, aber auch in GameObject (die Ausgabe wäre nur der Name) und toString() aus Object aufruft – dann wäre die Kennung die kryptische.

Doch führt die Laufzeitumgebung die Anweisungen aus, und nicht der Compiler. Da dem im Programmtext vereinbarten Variablentyp nicht zu entnehmen ist, welche Implementierung der Methode toString() aufgerufen wird, sprechen wir von später dynamischer Bindung, kurz dynamischer Bindung. Erst zur Laufzeit (das ist spät, im Gegensatz zur Übersetzungszeit) wählt die Laufzeitumgebung dynamisch die entsprechende Objektmethode aus – passend zum tatsächlichen Typ des aufrufenden Objekts. Die virtuelle Maschine weiß, dass hinter den drei Variablen immer ein Raum-Objekt steht, und ruft daher das toString() vom Room auf.

Wichtig ist, dass eine Methode überschrieben wird; von einer gleichlautenden Methode in beiden Unterklassen GameObject und Room hätten wir nichts, da sie nicht in Object deklariert ist. Sonst hätten die Klassen nur rein »zufällig« diese Methode, aber die Ober- und Unterklassen verbindet nichts. Wir nutzen daher ausdrücklich die Gemeinsamkeit, dass GameObject, Player und weitere Unterklassen toString() aus Object erben. Ohne die Oberklasse gäbe es kein Bindeglied, und folglich bietet die Oberklasse immer eine Methode an, die Unterklassen überschreiben können. Würden wir eine neue Unterklasse von Object schaffen und toString() nicht überschreiben, so fände die Laufzeitumgebung toString() in Object, aber die Methode gäbe es auf jeden Fall; entweder die Original-Methode oder die überschriebene Variante.

Begrifflichkeit

Dynamische Bindung wird oft auch Polymorphie genannt; ein dynamisch gebundener Aufruf ist dann ein polymorpher Aufruf. Das ist im Kontext von Java in Ordnung, allerdings gibt es in der Welt der Programmiersprachen unterschiedliche Dinge, die »Polymorphie« genannt werden, etwa parametrische Polymorphie (in Java heißt das dann Generics), und die Theoretiker kennen noch viel mehr beängstigende Begriffe.


Rheinwerk Computing - Zum Seitenanfang

5.11.2 Implementierung von System.out.println(Object)Zur nächsten ÜberschriftZur vorigen Überschrift

Werfen wir einen Blick auf ein Programm, das dynamisches Binden noch deutlicher macht. Die print()- und println()-Methoden sind so überladen, dass sie jedes beliebige Objekt annehmen und dann die String-Repräsentation ausgeben:

Listing 5.83: java/io/PrintStream.java, Skizze von println()

public void println( Object x )
{
String s = (x == null) ? "null" : x.toString();
print( s );
newLine();
}

Die println()-Methode besteht aus drei Teilen: Als Erstes wird die String-Repräsentation eines Objekts erfragt – hier findet sich der dynamisch gebundene Aufruf –, dann wird dieser String an print() weitergegeben, und newLine() produziert abschließend den Zeilenumbruch.

Der Compiler hat überhaupt keine Ahnung, was x ist; es kann alles sein, denn alles ist ein java.lang.Object. Statisch lässt sich aus dem Argument x nichts ablesen, und so muss die Laufzeitumgebung entscheiden, an welche Klasse der Methodenaufruf geht. Das ist das Wunder der dynamischen Bindung.

Abbildung
Eclipse zeigt bei der Tastenkombination Strg + T eine Typhierarchie an, standardmäßig die Oberklassen und bekannten Unterklassen.


Rheinwerk Computing - Zum Seitenanfang

5.11.3 Nicht dynamisch gebunden bei privaten, statischen und finalen MethodenZur nächsten ÜberschriftZur vorigen Überschrift

Obwohl Methodenaufrufe eigentlich dynamisch gebunden sind, gibt es bei privaten, statischen und finalen Methoden eine Ausnahme. Das liegt daran, dass nur überschriebene Methoden an dynamischer Bindung teilnehmen, und wenn es kein Überschreiben gibt, dann gibt es auch keine dynamische Bindung. Und da weder private noch statische oder finale Methoden überschrieben werden können, sind Methodenaufrufe auch nicht dynamisch gebunden. Sehen wir uns das an einer privaten Methode an:

Listing 5.84: NoPolyWithPrivate.java

class NoPolyWithPrivate
{
public static void main( String[] args )
{
Banana unsicht = new Banana();
System.out.println( unsicht.bar() ); // 2
}
}

class Fruit
{
private int furcht()
{
return 2;
}

int bar()
{
return furcht();
}
}

class Banana extends Fruit
{
// Überschreibt nicht, daher kein @Override
public int furcht()
{
return 1;
}
}

Der Compiler meldet bei der Methode furcht() in der Unterklasse keinen Fehler. Für den Compiler ist es in Ordnung, wenn es eine Methode in der Unterklasse gibt, die den gleichen Namen wie eine private Methode in der Oberklasse trägt. Das ist auch gut so, denn private Implementierungen sind ja ohnehin geheim und versteckt. Die Unterklasse soll von den privaten Methoden in der Oberklasse gar nichts wissen. Statt von Überschreiben sprechen wir hier von Überdecken.

Die Laufzeitumgebung macht etwas Erstaunliches für unsicht.bar(): Die Methode bar() wird aus der Oberklasse geerbt. Wir wissen, dass in bar() aufgerufene Methoden normalerweise dynamisch gebunden werden, das heißt, dass wir eigentlich bei furcht() in Unter landen müssten, da wir ein Objekt vom Typ Banana haben. Bei privaten Methoden ist das aber anders, da sie nicht vererbt werden. Wenn eine aufgerufene Methode den Modifizierer private trägt, wird nicht dynamisch gebunden, und unsicht.bar() bezieht sich bei furcht() auf die Methode aus Fruit.

System.out.println( unsicht.bar() );   // 2

Anders wäre es, wenn bei furcht() der Sichtbarkeitsmodifizierer public wäre; wir bekämen dann die Ausgabe 1.

Dass private und statische Methoden nicht überschrieben werden, ist ein wichtiger Beitrag zur Sicherheit. Falls nämlich Unterklassen interne private Methoden überschreiben könnten, wäre dies eine Verletzung der inneren Arbeitsweise der Oberklasse. In einem Satz: Private Methoden sind nicht in den Unterklassen sichtbar und werden daher nicht verdeckt oder überschrieben. Andernfalls könnten private Implementierungen im Nachhinein geändert werden, und Oberklassen wären nicht mehr sicher davor, dass tatsächlich ihre eigenen Methoden benutzt werden.

Schauen wir, was passiert, wenn wir in der Methode bar() über die this-Referenz auf ein Objekt vom Typ Banana casten:

int bar()
{
return ((Banana)(this)).furcht();
}

Dann wird ausdrücklich diese furcht() aus Banana aufgerufen, was jedoch kein typisches objektorientiertes Konstrukt darstellt, da Oberklassen ihre Unterklassen im Allgemeinen nicht kennen. bar() in der Klasse Ober ist somit unnütz.


Rheinwerk Computing - Zum Seitenanfang

5.11.4 Dynamisch gebunden auch bei Konstruktoraufrufen *Zur nächsten ÜberschriftZur vorigen Überschrift

Dass ein Konstruktor der Unterklasse zuerst den Konstruktor der Oberklasse aufruft, kann die Initialisierung der Variablen in der Unterklasse stören. Schauen wir uns erst Folgendes an:

class Bouncer extends Bodybuilder
{
String who = "Ich bin ein Rausschmeißer";
}

Wo wird nun die Variable who initialisiert? Wir wissen, dass die Initialisierungen immer im Konstruktor vorgenommen werden, doch gibt es ja noch gleichzeitig ein super() im Konstruktor. Da die Spezifikation von Java Anweisungen vor super() verbietet, muss die Zuweisung hinter dem Aufruf der Oberklasse folgen. Das Problem ist nun, dass ein Konstruktor der Oberklasse früher aufgerufen wird, als Variablen in der Unterklasse initialisiert wurden. Wenn es die Oberklasse nun schafft, auf die Variablen der Unterklasse zuzugreifen, wird der erst später gesetzte Wert fehlen. Der Zugriff gelingt tatsächlich, doch nur durch einen Trick, da eine Oberklasse (etwa Bodybuilder) nicht auf die Variablen der Unterklasse zugreifen kann. Wir können aber in der Oberklasse genau jene Methode der Unterklasse aufrufen, die die Unterklasse aus der Oberklasse überschreibt. Da Methodenaufrufe dynamisch gebunden werden, kann eine Methode den Wert auslesen:

Listing 5.85: Bouncer.java

class Bodybuilder
{
Bodybuilder()
{
whoAmI();
}

void whoAmI()
{
System.out.println( "Ich weiß es noch nicht :-(" );
}
}

public class Bouncer extends Bodybuilder
{
String who = "Ich bin ein Rausschmeißer";

@Override
void whoAmI()
{
System.out.println( who );
}

public static void main( String[] args )
{
Bodybuilder bb = new Bodybuilder();
bb.whoAmI();

Bouncer bouncer = new Bouncer();
bouncer.whoAmI();
}
}

Die Ausgabe ist nun folgende:

Ich weiß es noch nicht :-(
Ich weiß es noch nicht :-(
null
Ich bin ein Rausschmeißer

Das Besondere an diesem Programm ist die Tatsache, dass überschriebene Methoden – hier whoAmI() – dynamisch gebunden werden. Diese Bindung gibt es auch dann schon, wenn das Objekt noch nicht vollständig initialisiert wurde. Daher ruft der Konstruktor der Oberklasse Bodybuilder nicht whoAmI() von Bodybuilder auf, sondern whoAmI() von Bouncer. Wenn in diesem Beispiel ein Bouncer-Objekt erzeugt wird, dann ruft Bouncer mit super() den Konstruktor von Bodybuilder auf. Dieser ruft wiederum die Methode whoAmI() in Bouncer auf, und er findet dort keinen String, da dieser erst nach super() gesetzt wird. Schreiben wir den Konstruktor von Bouncer einmal ausdrücklich hin:

public class Bouncer extends Bodybuilder
{
String who;

Bouncer()
{
super();
who = "Ich bin ein Rausschmeißer";
}
}

Die Konsequenz, die sich daraus ergibt, ist folgende: Dynamisch gebundene Methodenaufrufe über die this-Referenz sind in Konstruktoren potenziell gefährlich und sollten deshalb vermieden werden. Vermeiden lässt sich das, indem der Konstruktor nur private (oder finale) Methoden aufruft, da diese nicht dynamisch gebunden werden. Wenn der Konstruktor eine private (finale) Methode in seiner Klasse aufruft, dann bleibt es auch dabei.


Rheinwerk Computing - Zum Seitenanfang

5.11.5 Eine letzte Spielerei mit Javas dynamischer Bindung und überschatteten Attributen *Zur vorigen Überschrift

Werfen wir einen Blick auf folgendes Java-Programm:

Listing 5.86: SubBoaster.java

class SuperBoaster
{
int no = 1;

void boast()

{
System.out.println( "Ich bin die Nummer " + no );
}
}

public class SubBoaster extends SuperBoaster
{
int no = 2;

@Override void boast()
{
super.boast(); // Ich bin die Nummer 1
System.out.println( super.no ); // 1
System.out.println( no ); // 2
}

public static void main( String[] args )
{
new SubBoaster().boast();
}
}

Die Methode boast() aus SubBoaster ruft mit super.boast() die Methode der Oberklasse auf. Ein einfacher Aufruf von boast() in der Unterklasse würde in eine Rekursion führen. Die Unterklasse hat mit super.nr Zugriff auf die überschattete Objektvariable nr aus der Oberklasse. super ist wie this eine spezielle Referenz und kann auch genauso eingesetzt werden, nur dass super in den Namensraum der Oberklasse geht. Eine Aneinanderreihung von super-Schlüsselwörtern bei einer tieferen Vererbungshierarchie ist nicht möglich. Hinter einem super muss eine Objekteigenschaft stehen, und Anweisungen wie super.super.nr sind somit immer ungültig. Für Variablen gibt es eine Möglichkeit, die sich durch einen Cast in die Oberklasse ergibt. Setzen wir in boast() der Unterklasse folgende Anweisung:

System.out.println( ((SuperBoaster) this).nr );      // 1

Die Ausgabe 1 ist also identisch mit System.out.println(super.nr). Die this-Referenz entspricht einem Objekt vom Typ SubBoaster. Wenn wir dies aber in den Typ SuperBoaster konvertieren, bekommen wir genau das nr aus der Basisklasse unserer Hierarchie. Wir erkennen hier eine sehr wichtige Eigenschaft von Java, nämlich dass Variablen nicht dynamisch gebunden werden. Anders sieht es aus, wenn wir Folgendes in die Methode boast()der Unterklasse SubBoaster setzen:

((SuperBoaster)this).boast();

Hier ruft die Laufzeitumgebung nicht boast() aus SuperBoaster auf, sondern die aktuelle Methode boast() aus SubBoaster, sodass wir in einer Rekursion landen. Der Grund dafür liegt in der dynamischen Bindung zur Laufzeit, die ein Compiler-Typecast nicht ändert.



Ihr Kommentar

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

>> Zum Feedback-Formular
<< 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

 Buchempfehlungen
Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Java SE Bibliotheken






 Java SE Bibliotheken


Zum Katalog: Professionell entwickeln mit Java EE 7






 Professionell
 entwickeln mit
 Java EE 7


Zum Katalog: Einstieg in Eclipse






 Einstieg in
 Eclipse


Zum Katalog: Einstieg in Java






 Einstieg in
 Java


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2011
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.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de