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

 << zurück
Praxisbuch Objektorientierung von Bernhard Lahres, Gregor Raýman
Professionelle Entwurfsverfahren
Buch: Praxisbuch Objektorientierung

Praxisbuch Objektorientierung
609 S., 49,90 Euro
Rheinwerk Computing
ISBN 3-89842-624-6
gp Kapitel 3 Die Prinzipien des objektorientierten Entwurfs
  gp 3.1 Prinzip 1: Prinzip einer einzigen Verantwortung
  gp 3.2 Prinzip 2: Trennung der Anliegen
  gp 3.3 Prinzip 3: Wiederholungen vermeiden
  gp 3.4 Prinzip 4: Offen für Erweiterung, geschlossen für Änderung
  gp 3.5 Prinzip 5: Trennung der Schnittstelle von der Implementierung
  gp 3.6 Prinzip 6: Umkehr der Abhängigkeiten
    gp 3.6.1 Umkehrung des Kontrollflusses
  gp 3.7 Prinzip 7: Mach es testbar


Rheinwerk Computing

3.5 Prinzip 5: Trennung der Schnittstelle von der Implementierung  toptop

Der Zusammenhang zwischen der Spezifikation der Schnittstelle eines Moduls und der Implementierung sollte nur für die Erstellung des Moduls selbst eine Rolle spielen. Alle anderen Module sollten die Details der Implementierung ignorieren.

Abbildung


Trennung der Schnittstelle von der Implementierung (program to interfaces)

Jede Abhängigkeit zwischen zwei Modulen sollte explizit formuliert und dokumentiert sein. Ein Modul sollte immer von einer klar definierten Schnittstelle des anderen Moduls abhängig sein und nicht von der Art der Implementierung der Schnittstelle. Die Schnittstelle eines Moduls sollte getrennt von der Implementierung betrachtet werden können.


Schnittstelle ist Spezifikation

In der obigen Definition dürfen Sie unter dem Begriff Schnittstelle nicht nur bereitgestellte Funktionen und deren Parameter verstehen. Der Begriff Schnittstelle bezieht sich vielmehr auf die komplette Spezifikation, die festlegt, welche Funktionalität ein Modul anbietet.

Durch das Befolgen des Prinzips der Trennung der Schnittstelle von der Implementierung wird es möglich, Module auszutauschen, welche die Schnittstelle implementieren. Das Prinzip ist auch unter der Formulierung Programmiere gegen Schnittstellen, nicht gegen Implementierungen bekannt.

Abbildung

Protokollausgaben

Nehmen Sie als ein einfaches Beispiel ein Modul, das für die Ausgabe von Fehler- und Protokollmeldungen zuständig ist. Unsere Implementierung gibt die Meldungen einfach über die Standardausgabe auf dem Bildschirm als Text aus.

Wenn andere Module, die diese Funktionalität nutzen, sich darauf verlassen, dass die Fehlermeldungen über die Standardausgabe auf dem Bildschirm erscheinen, kann das zu zweierlei Problemen führen. Probleme treten z. B. dann auf, wenn Sie das Protokollmodul so ändern möchten, dass die Meldungen in einer Datenbank gespeichert oder per E-Mail verschickt werden. In Abbildung 3.6 ist das Problem illustriert.

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

Abbildung 3.6   Trennung der Schnittstelle von der Implementierung

Problem 1: Funktionalität nicht genutzt

Dieses Problem kann daraus resultieren, dass andere Module die bereitgestellte Funktionalität gar nicht nutzen, sondern eine äquivalente Funktionalität selbst implementieren. Es ist doch so einfach, eine Meldung über die Standardausgabe auszugeben. Jedes »Hello World«-Programm macht es, warum also ein spezielles Protokollmodul nutzen? Ersetzen Sie jetzt das Protokollmodul durch ein anderes, das die Meldungen in einer Datenbank speichert, werden bestimmte Meldungen tatsächlich in der Datenbank landen, andere dagegen immer noch auf der Standardausgabe erscheinen. Dieses Problem haben wir bereits in Abschnitt 3.3 angesprochen.

Problem 2: Sich auf die Implementierung verlassen

Ein anderes Problem kann für die Module entstehen, welche die Fehlermeldungen einlesen und auswerten. Wenn sich diese Module darauf verlassen, dass die Fehlermeldungen über die Standardausgabe ausgegeben werden, können sie z. B. die Umleitung der Standardausgabe dafür nutzen, um die Meldungen einzulesen. Werden die Meldungen nicht mehr über die Standardausgabe ausgegeben, werden die abhängigen Module nicht mehr funktionieren.

Sie können die geschilderten Probleme vermeiden, indem Sie sich in Ihren Modulen nur auf die Definition der Schnittstelle anderer Module verlassen. Dabei müssen diese jeweils ihre Schnittstelle möglichst klar definieren und dokumentieren.

Abbildung

Verwendung von Schriftgrößen

Ein anderes Beispiel der Probleme, die sich daraus ergeben, wenn man sich statt der Schnittstelle auf deren konkrete Implementierung verlässt, lässt sich leider viel zu oft beobachten, wenn Sie unter Windows die Bildschirmauflösung und die Größe der Fonts ändern. Zu viele Anwendungen gehen davon aus, dass die Bildschirmauflösung 96 dpi beträgt (Kleine Schriftarten), ändert man die Auflösung auf Große Schriftarten (120 dpi), sehen sie merkwürdig aus oder lassen sich gar nicht mehr benutzen.

Das Problem besteht darin, dass sich die Anwendungen auf eine bestimmte Implementierung der Darstellung der Texte auf dem Bildschirm verlassen. Sie verlassen sich darauf, dass für einen bestimmten Text ein Bereich des Bildschirms von bestimmter Größe gebraucht wird. Dies ist jedoch nur ein nicht versprochenes Detail der Implementierung, nicht eine in der Schnittstelle der Textdarstellung unter Windows definierte Funktionalität.

Vorsicht: Java- und C#-Interfaces

Die Programmiersprachen Java und C# bietet in ihren Konstrukten eine Trennung zwischen Klassen und Schnittstellen (Interfaces). Sie könnten nun annehmen, dass Sie das Prinzip schon dann erfüllen, wenn Sie in Ihren Modulen vorrangig mit Java- oder C#-Schnittstellen anstelle von konkreten Klassen arbeiten. Dies ist aber nicht so. Das Prinzip bezieht sich vielmehr darauf, dass Sie keine Annahmen über die konkreten Implementierungen machen dürfen, die hinter einer Schnittstelle liegen. Diese Annahmen können Sie aber bei Java- und C#-Interfaces genauso machen wie bei anderen Klassen.

 << zurück
  
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchtipps
Neuauflage: Objektorientierte Programmierung






 Neuauflage:
 Objektorientierte
 Programmierung


Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Schrödinger programmiert C++






 Schrödinger
 programmiert C++


Zum Katalog: C++ Handbuch






 C++ Handbuch


Zum Katalog: Einstieg in Python






 Einstieg in Python


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo





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


Nutzungsbestimmungen | Datenschutz | Impressum

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