Objektorientierte Programmierung OOP

In der Programmierung versucht man das Verhalten von der konkreten Implementierung zu trennen. Für die Verwendung eines Programms bzw. einer Klasse muss lediglich bekannt sein, was für eine Funktionalität geboten wird, aber nicht wie genau sie umgesetzt ist. Dieses Konzept nennen wir auch Geheimnisprinzip, da die genaue Implementierung für Außenstehende ein Geheimnis ist. Dieses Prinzip bringt eine Reihe von Vorteilen mit sich. Da die Interna der Klasse nach außen hin nicht bekannt sind, verursachen Änderungen an der Implementierung keine Probleme, solange die vereinbarte Funktionalität beibehalten wird.

Eine Klasse ist öffentlich (engl. public) zugänglich, falls in der Klassendefinition dem Schlüsselwort class das Schlüsselwort public vorangestellt ist:

public class className {

    ...

}

Eine öffentliche Klasse ist in allen Paketen sichtbar. Falls public fehlt, so ist lediglich der Standardzugriff (engl. default access) von innerhalb des Pakets, zu dem die Klasse gehört, möglich. Andere Zugriffsmodifikatoren sind bei eigenständigen Klassen nicht zulässig. [JLS: § 6.6.1]

Gegeben seien die Pakete a, a.c und b mit den folgenden Klassendeklarationen.

package a;

class K {

     // Hier sind die Klassen

     // L, M und N sichtbar

}

public class L {

     // Hier sind die Klassen

     // K, L und N sichtbar

}

package a.c;

public class M {

     // Hier sind die Klassen

     // L und N sichtbar

}

package b;

public class N {

     // Hier sind die Klassen

     // L, M und P sichtbar

}

class P {

     // Hier sind die Klassen

     // L, M und N sichtbar

}

Bei der Attributdeklaration kann dem Typen noch ein Zugriffsmodifikator vorange stellt werden. [JLS: § 8.3.1]

Zugriffsmodifikator Typ Name;

Treten bei einer Attributdeklaration sowohl ein Zugriffsmodifikator als auch das Schlüsselwort final oder static auf, so wird zuerst der Zugriffsmodifkator und anschließend static und dann final genannt

Zugriffskontrolle bei Bei der Methodendeklaration kann dem Ergebnistyp noch ein Zugriffsmodifikator Methoden vorangestellt werden. [JLS: § 8.4.3]   Zugriffsmodifikator Ergebnistyp Name(Parameterliste) { }

Bei der Konstruktordeklaration kann dem Namen noch ein Zugriffsmodifikator vor- Zugriffskontrolle bei angestellt werden. [JLS: § 8.8.3] Konstruktoren  

Zugriffsmodifikator Name(Parameterliste) {

}

Ein Klassenelement, dass als public deklariert ist, ist überall dort sichtbar, wo auch die Klasse sichtbar ist.

Mit unseren jetzigen Kenntnissen ist es uns auch möglich, alle Bestandteile der  main()-Methode zu verstehen. Die main()-Methode ist eine öffentliche (public) Klassenmethode (static), die kein Ergebnis zurückgibt (void) und als einziges Argument ein Zeichenkettenfeld (String[] args) akzeptiert. Soll im Programm auf die übergebenen Argumente zugegriffen werden, so kann dies über das Zeichenkettenfeld geschehen. Werden zum Beispiel Zahlen übergeben, so müssen diese mit geeigneten Methoden der API in Werte primitiver Datentypen konvertiert werden.

Ein Klassenelement, dessen Deklaration keinen Zugriffsmodifikator enthält, ist innerhalb des Paketes sichtbar, in dem die zugehörige Klasse enthalten ist. [JLS: § 6.6.1]

Ein Klassenelement, dass als private deklariert ist, ist nur innerhalb der Klasse sichtbar

Attribute werden in der Regel als private deklariert, damit sie so von außerhalb der Klasse nicht direkt verändert werden können. Auch Hilfsmethoden werden in der Regel als private deklariert.

Ein Klassenelement, dass als protected deklariert ist, ist innerhalb des Paketes der Klasse sichtbar. Eine Unterklasse U hat auch außerhalb des Pakets der Oberklasse O Zugriff auf dieses Element. Dazu muss jedoch O als öffentlich deklariert sein, und der Zugriff muss an einem Element vom Typ U oder einem Subtyp von U ausgeführt werden. [JLS: § 6.6.1, § 6.6.2]

Methoden und Attribute die nicht jedem Benutzer zur Verfügung stehen sollen, jedoch von Unterklassen benötigt werden, werden in der Regel als protected deklariert.

Siehe Abbildung

Die Zugriffmodifikatoren für Klassenelemente können auch in der UML dargestellt werden. Die UML bietet wie Java vier verschiedene Modifikatoren (VisibilityKind): public, private, protected und package. Dabei entspricht package dem Standardzugriff von Java. Die Bedeutung von protected unterscheidet sich jedoch, da in der UML dieser Modifikator andeutet, dass nur Unterklassen Zugriff auf dieses Element haben, Klassen im gleichen Paket jedoch nicht. Die Modifikatoren werden in der UML dem Methodennamen vorangestellt und durch die folgenden Zeichen dargestellt: siehe Abbildung

Beim Überschreiben von Methoden darf der Zugriff in der Unterklasse höchstens erweitert, aber niemals eingeschränkt werden. d. h. der Zugriffsmodifikator der Methode in der Unterklasse muss größer und gleich dem der Oberklasse sein [JLS: § 8.4.8.3]. Dabei gilt die folgende Ordnung:

public > protected > Standardzugriff > private.

Für die Vererbung gelten für Klassen folgende Regeln:

• Eine Unterklasse erbt alle öffentlichen Attribute und Methoden der Oberklasse,

• alle geschützten Attribute und Methoden der Oberklasse sowie

• alle Attribute und Methoden ohne Zugriffsmodifikator der Oberklasse, wenn sich die Oberklasse im gleichen Paket befindet.

Konstruktoren werden nicht vererbt.

Eine finale Klasse kann nicht erweitert, also auch nicht beerbt werden.

Eine abstrakte Klasse wird durch das vorangestellte Schlüsselwort abstract vereinbart. [JLS: § 8.1.1.1]  Von abstrakten Klassen können keine Exemplare erzeugt werden. Eine abstrakte Klasse kann abstrakte Methoden besitzen.

Eine abstrakte Methode weist nur eine Signatur und einen Ergebnistyp oder void auf und wird durch das vorangestellte Schlüsselwort abstract vereinbart. [JLS: § 8.4.3.1] Die Vereinbarung einer abstrakten Methode wird mit einem Semikolon abgeschlossen: Zugriffsmodifikator abstract Ergebnistyp Name(Parameterliste);

Wenn in einer Klasse eine oder mehrere Methoden als abstract vereinbart sind, muss die Klasse auch als abstract vereinbart sein.

Eine Klasse kann jedoch auch als abstract erklärt werden, wenn keine ihrer Methoden als abstract deklariert ist.

Für abstrakte Klassen gelten folgende Vererbungsregeln:

• Jede konkrete Klasse, die von einer abstrakten Klasse erbt, muss die von der abstrakten Klasse geerbten abstrakten Methoden überschreiben und implementieren.

• Wenn eine oder mehrere abstrakte Methoden der abstrakten Oberklasse in der Unterklasse nicht implementiert werden, dann bleiben diese Methoden abstrakt, und die Unterklasse muss auch abstrakt sein.

In der UML können abstrakte Klassen mit dem Stereotyp <<abstract>> gekennzeichnet werden.

Abstrakte Klassen sind nützlich, wenn wir für manche Methoden Implementierungen angeben wollen und für andere nicht. Die Implementierung einer abstrakten Methode in verschiedenen Unterklassen muss mit der Vereinbarung der abstrakten Methode übereinstimmen. Die Vereinbarung abstrakter Methode empfiehlt sich, wenn für eine Methode keine sinnvolle Standardimplementierung in einer Oberklasse angegeben werden kann.

Als Service für Käufer von Blumentöpfen und anderen Pflanzgefäßen soll das Volumen der insgesamt benötigten Blumenerde berechnet werden. Wir verwenden eine kleine Klassenhierarchie mit verschiedenen Arten von Pflanzgefäßen als Subklassen einer abstrakten Oberklasse Pflanzgefaess. Die Abbildung zeigt die Subklassen Topf für konische Blumentöpfe und Kiste für quaderförmige Blumenkisten.

In Kurzeinheit 4 S.279 finden Sie das komplette Beispiel.

Da jeder Artikel in einem Blumenladen einer möglichst spezifischen Warengruppe angehören sollte, ist es durchaus sinnvoll, die Erzeugung von Objekten allgemeiner Oberklassen zu verhindern. So könnten etwa die Klasse Artikel oder auch andere Oberklassen wie Pflanze als abstract deklariert werden.

Ein Konstruktor kann nicht als abstract deklariert werden. Da Konstruktoren nicht überschrieben werden können, gibt es keine Möglichkeit, einen Konstruktor erst in einer abgeleiteten Klasse zu implementieren. Eine abstrakte Klasse darf aber  durchaus Konstruktoren implementieren, die dann von Unterklassen mit Hilfe von  super() verwendet werden können.

Als private deklarierte Methoden können nicht als abstract vereinbart werden. Der Grund für diese Einschränkung liegt auf der Hand: sie könnten in einer abgeleiteten Klasse nicht überschrieben werden, weil private Methoden und Attribute außerhalb der definierenden Klasse nicht sichtbar sind. Statische Methoden können ebenfalls nicht als abstract vereinbart werden. Java lässt es auch nicht zu, eine Klasse als final und abstract zu deklarieren. Wenn eine Klasse als final vereinbart wird, drücken wir damit aus, dass von dieser Klasse keine Unterklassen abgeleitet werden können. Damit besteht auch keine Möglichkeit, abstrakte Methoden in dieser Klasse zu vereinbaren. Analog können auch Methoden nicht als final und abstract deklariert werden.

Treten bei einer Klasse oder bei einer Methode die Modifikatoren public und abstract gemeinsam auf, so wird zuerst public genannt.

Eine Schnittstelle wird wie folgt vereinbart [JLS: § 9.1]:

interface Schnittstellenname {

    Attributdeklarationen

    Methodendeklarationen

}

Für Schnittstellen gelten folgende Vererbungsregeln:

• Schnittstellen können von anderen Schnittstellen erweitert (engl. extend) werden. Sie können jedoch nicht durch Klassen erweitert werden.

• Klassen können Schnittstellen lediglich implementieren.

• Eine Klasse kann mehrere Schnittstellen implementieren.

• Schnittstellenmethoden müssen in einer Klassenimplementierung als public vereinbart werden, da alle Schnittstellenmethoden implizit public sind.

• Wenn Klasse A Schnittstelle B implementiert, ist A ein Subtyp von B. Somit kann ein Objekt vom Typ A überall dort verwendet werden, wo ein Objekt vom Typ B erwartet wird.

• Eine Klasse kann zugleich eine (oder mehrere) Schnittstelle(n) implementieren und eine Klasse erweitern.

Java benutzt das Schlüsselwort implements, um anzuzeigen, dass eine Klasse eine oder mehrere Schnittstellen implementiert [JLS: § 8.1.5]:

class Klassenname implements I [, I2, ..., In ] {

    ...  

}

In UML-Klassendiagrammen werden Schnittstellen durch das Stereotyp <<interface>> gekennzeichnet. Eine implements-Beziehung wird durch  einen Pfeil mit gestrichelter Linie und unausgefüllter Pfeilspitze ausgedrückt.

Bei Schnittstellen wird in Java das Prinzip der Einfachvererbung durchbrochen und eine Art von Mehrfachvererbung (engl. multiple inheritance) zugelassen. Mehrfachvererbung bedeutet, dass ein Typ mehrere Obertypen hat.

Bekanntlich ist jede Klasse ein Subtyp in einer Klassenhierarchie, entweder ein direkter Subtyp der Klasse Object, oder Subtyp einer spezielleren Klasse wie die Spezialisierungen der Klasse Artikel, die wir schon mehrfach als Beispiele verwendet haben. Eine Klasse, die eine Schnittstelle implementiert, ist zusätzlich auch ein Subtyp dieser Schnittstelle, was wir mit dem instanceof-Operator leicht  überprüfen können: 

public class A {}

public interface B {}

public interface BB {}

public interface BBB extends B, BB {}

public class C extends A implements BBB {

public static void main(String[] args) {

C myC = new C();

System.out.println(myC instanceof A

&& myC instanceof B

&& myC instanceof BB

&& myC instanceof BBB

&& myC instanceof Object); // prints true

}

}

Mehrfachvererbung durch Schnittstellen lässt sich nutzen, um Klassen mit Eigenschaften auszustatten, die nicht entlang der Klassenhierarchie organisiert sind.