© Excellent backgrounds/Shutterstock.com
Java Magazin
Java-API-Design

Futurama - Nichts ist so beständig wie die Veränderung

Damit einmal getroffene Entscheidungen auf lange Sicht keine Dramen verursachen, sind einige Spielregeln zu beachten. Ganz besonders gilt das für den Entwurf eines API, das naturgemäß über einen langen Zeitraum Verwendung findet.

Marco Schulz


Die Motivation, für eine eigene Anwendung und vor allem für Programmbibliotheken eine definierte Schnittstelle bereitzustellen, die die Interaktion mit anderen Programmen ermöglicht, ist in vielen Projekten sehr hoch. Doch nicht immer gelingt dieses Vorhaben. Deutlichste Anzeichen für ein verunglücktes API sind häufige Änderungen, die mit Vorgängerversionen inkompatibel sind. Die damit verbundenen Probleme kennt jeder, der einmal innerhalb eines Projekts eine vorhandene Bibliothek gegen eine neuere Version austauschen musste. Je nach Intensität der Nutzung erfordert ein Update kleinere oder sogar sehr große Codeanpassungen.

Aber auch bei korrekter Durchführung ist die bei Verwendung eines API erwartete Flexibilität nicht immer gewährleistet. Theoretisch ist es bei einem korrekten Entwurf möglich, die Implementierung zu einem API problemlos auszutauschen. In realen Projekten tritt dieser Idealfall eher selten ein. Die Ursache ist recht trivial: Solange die Hersteller einer Implementierung dem vom API definierten Standard komplett folgen, ist alles optimal. Ein Beispiel für einen solchen Standard ist die Java Database Connectivity (JDBC). Viele Datenbankhersteller, die für ihr DBMS die JDBC implementieren, haben jedoch mit Schwierigkeiten zu kämpfen. Denn die Systeme unterscheiden sich in einigen Details. So kennt MySQL zum Erzeugen des Primärschlüssels Auto Increment – eine Funktion, die bei Enterprise-Lösungen fehlt. Solche Feinheiten haben zur Folge, dass viele Contributors den Standard nicht komplett implementieren. Ebenso sind Erweiterungen außerhalb der festgelegten Definition häufig. Deshalb sollte klar sein, dass ein einen Standard definierendes API einen Kompromiss aus minimalen Anforderungen darstellt. So lässt sich sehr leicht einsehen, welche Komplikationen sich bei einem Austausch der Implementierungen ergeben können.

Die Verarbeitung von XML zeigt einen anderen Aspekt auf. Es existieren die Standards DOM, SAX und StAX. Entscheidet man sich bei der Implementierung ursprünglich für DOM und steigt aus Gründen der Performanceverbesserung auf SAX um, stellt man schnell fest: Beide Implementierungen und APIs sind weitgehend inkompatibel. Das Problem lässt sich anhand des Beispiels PDF-Verarbeitung konkretisieren. Obwohl es sich bei PDF um einen Standard handelt, existiert für Programmbibliotheken keine allgemein definierte Schnittstelle. Entsprechend präsentiert sich der Datentyp PdfReader in der iText-Bibliothek [1]. Dieser definiert für das eigene...

Java Magazin
Java-API-Design

Futurama - Nichts ist so beständig wie die Veränderung

Damit einmal getroffene Entscheidungen auf lange Sicht keine Dramen verursachen, sind einige Spielregeln zu beachten. Ganz besonders gilt das für den Entwurf eines API, das naturgemäß über einen langen Zeitraum Verwendung findet.

Marco Schulz


Die Motivation, für eine eigene Anwendung und vor allem für Programmbibliotheken eine definierte Schnittstelle bereitzustellen, die die Interaktion mit anderen Programmen ermöglicht, ist in vielen Projekten sehr hoch. Doch nicht immer gelingt dieses Vorhaben. Deutlichste Anzeichen für ein verunglücktes API sind häufige Änderungen, die mit Vorgängerversionen inkompatibel sind. Die damit verbundenen Probleme kennt jeder, der einmal innerhalb eines Projekts eine vorhandene Bibliothek gegen eine neuere Version austauschen musste. Je nach Intensität der Nutzung erfordert ein Update kleinere oder sogar sehr große Codeanpassungen.

Aber auch bei korrekter Durchführung ist die bei Verwendung eines API erwartete Flexibilität nicht immer gewährleistet. Theoretisch ist es bei einem korrekten Entwurf möglich, die Implementierung zu einem API problemlos auszutauschen. In realen Projekten tritt dieser Idealfall eher selten ein. Die Ursache ist recht trivial: Solange die Hersteller einer Implementierung dem vom API definierten Standard komplett folgen, ist alles optimal. Ein Beispiel für einen solchen Standard ist die Java Database Connectivity (JDBC). Viele Datenbankhersteller, die für ihr DBMS die JDBC implementieren, haben jedoch mit Schwierigkeiten zu kämpfen. Denn die Systeme unterscheiden sich in einigen Details. So kennt MySQL zum Erzeugen des Primärschlüssels Auto Increment – eine Funktion, die bei Enterprise-Lösungen fehlt. Solche Feinheiten haben zur Folge, dass viele Contributors den Standard nicht komplett implementieren. Ebenso sind Erweiterungen außerhalb der festgelegten Definition häufig. Deshalb sollte klar sein, dass ein einen Standard definierendes API einen Kompromiss aus minimalen Anforderungen darstellt. So lässt sich sehr leicht einsehen, welche Komplikationen sich bei einem Austausch der Implementierungen ergeben können.

Die Verarbeitung von XML zeigt einen anderen Aspekt auf. Es existieren die Standards DOM, SAX und StAX. Entscheidet man sich bei der Implementierung ursprünglich für DOM und steigt aus Gründen der Performanceverbesserung auf SAX um, stellt man schnell fest: Beide Implementierungen und APIs sind weitgehend inkompatibel. Das Problem lässt sich anhand des Beispiels PDF-Verarbeitung konkretisieren. Obwohl es sich bei PDF um einen Standard handelt, existiert für Programmbibliotheken keine allgemein definierte Schnittstelle. Entsprechend präsentiert sich der Datentyp PdfReader in der iText-Bibliothek [1]. Dieser definiert für das eigene...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang