© Liashko/Shutterstock.com
Entwickler Magazin
Grundlagen des API-Designs mit Java

Mit der Macht von Java

Wer sich mit C++ nicht anfreunden kann, sucht sein Glück in der Java-Welt. Dieser alte Kalauer ist zumindest insofern wahr, als die beiden Sprachen einander in vielerlei Hinsicht stark ähneln. Der wichtigste Unterschied ist jedoch, dass Java in puncto Aufbau rigider ist und mit Managed Memory aufwartet. Analog zu C++ gilt aber auch im Fall von Java, dass die Programmiersprache - trotz diverser Versuche - nicht auszurotten ist. Was es beim API-Design für diese Plattform zu beachten gilt, zeigt dieser Artikel.

Tam Hanna


Vor der Arbeit an einem API sollte man natürlich überlegen, was am Ende der Arbeiten entstehen soll. Auch wenn Java aufgrund der rigideren Spezifikation weniger Spielraum bietet als C++, sind in der Literatur trotzdem drei verschiedene API-Arten bekannt.

Eine Frage der Gestalt

Am unteren Ende der Komplexitätshierarchie finden sich hierbei Utility-Bibliotheken, die im Grunde genommen aus einer Gruppe statischer Methoden bestehen. Entwickler suchen sich eine oder mehrere für sie interessante Funktionen aus, integrieren sie in ihr Programm und freuen sich ob der eingesparten Zeit. Im Idealfall sind die in einem Utility-API enthaltenen Funktionen komplett zustandslos. Ist dies aus irgendeinem Grund nicht möglich, so bietet sich beispielsweise die Nutzung eines bei jedem Aufruf zu übergebenden Statusobjekts an.

Services und Frameworks sind im Vergleich dazu wesentlich komplexere Aufbauten, die dem Entwickler wesentlich mehr Vorschriften in Bezug auf das Hantieren mit den Elementen auferlegen. Der wichtigste Unterschied zwischen einem Service und einem Framework ist – aus akademischer Sicht – die Kontrolle: Ein Service ist eine Abstraktionsschicht, die den Programmierer, wie in Abbildung 1 gezeigt, von der internen Architektur des anzusprechenden Diensts isoliert.

Abb. 1: Dank des Service-API muss der Entwickler nichts über Remote Procedure Calls wissen

Frameworks setzen stattdessen auf eine Inversion der Kontrolle. Sie errichten eine mehr oder weniger komplexe Ausführungsumgebung, in der der Entwickler seine Logik dann in Form von Callbacks oder ähnlichen Sprach­elementen einschreibt.

Beim Design eines Frameworks ist es – insbesondere für wenig etablierte Unternehmen – ratsam, „minimalinvasiv“ vorzugehen. Wenn Facebook oder Google einem Entwickler ein bestimmtes Design Pattern vorschreiben, wird er dieses grummelnd akzeptieren. Ob er dies auch bei weniger etablierten Playern macht, darf bezweifelt werden.

Schnelle Auslieferung

Eines der stärksten Verkaufsargumente für Gradle bzw. Android Studio ist mit Sicherheit die Möglichkeit, Bibliotheken durch Anpassen einer Datei in ein Projekt zu integrieren: Download und Co. erledigt der Build Daemon automatisch. Aus der Logik folgt, dass das hauseigene API – wann immer aus lizenzrechtlichen Gründen möglich – über den Bibliotheksmanager der meistverwendeten Programmierumgebung der Zielgruppe bereitgestellt werden sollte. Wer seine Android-Bibliothek also nicht im Gradle Repository hostet, muss sich über langsamere Adaption n...

Entwickler Magazin
Grundlagen des API-Designs mit Java

Mit der Macht von Java

Wer sich mit C++ nicht anfreunden kann, sucht sein Glück in der Java-Welt. Dieser alte Kalauer ist zumindest insofern wahr, als die beiden Sprachen einander in vielerlei Hinsicht stark ähneln. Der wichtigste Unterschied ist jedoch, dass Java in puncto Aufbau rigider ist und mit Managed Memory aufwartet. Analog zu C++ gilt aber auch im Fall von Java, dass die Programmiersprache - trotz diverser Versuche - nicht auszurotten ist. Was es beim API-Design für diese Plattform zu beachten gilt, zeigt dieser Artikel.

Tam Hanna


Vor der Arbeit an einem API sollte man natürlich überlegen, was am Ende der Arbeiten entstehen soll. Auch wenn Java aufgrund der rigideren Spezifikation weniger Spielraum bietet als C++, sind in der Literatur trotzdem drei verschiedene API-Arten bekannt.

Eine Frage der Gestalt

Am unteren Ende der Komplexitätshierarchie finden sich hierbei Utility-Bibliotheken, die im Grunde genommen aus einer Gruppe statischer Methoden bestehen. Entwickler suchen sich eine oder mehrere für sie interessante Funktionen aus, integrieren sie in ihr Programm und freuen sich ob der eingesparten Zeit. Im Idealfall sind die in einem Utility-API enthaltenen Funktionen komplett zustandslos. Ist dies aus irgendeinem Grund nicht möglich, so bietet sich beispielsweise die Nutzung eines bei jedem Aufruf zu übergebenden Statusobjekts an.

Services und Frameworks sind im Vergleich dazu wesentlich komplexere Aufbauten, die dem Entwickler wesentlich mehr Vorschriften in Bezug auf das Hantieren mit den Elementen auferlegen. Der wichtigste Unterschied zwischen einem Service und einem Framework ist – aus akademischer Sicht – die Kontrolle: Ein Service ist eine Abstraktionsschicht, die den Programmierer, wie in Abbildung 1 gezeigt, von der internen Architektur des anzusprechenden Diensts isoliert.

Abb. 1: Dank des Service-API muss der Entwickler nichts über Remote Procedure Calls wissen

Frameworks setzen stattdessen auf eine Inversion der Kontrolle. Sie errichten eine mehr oder weniger komplexe Ausführungsumgebung, in der der Entwickler seine Logik dann in Form von Callbacks oder ähnlichen Sprach­elementen einschreibt.

Beim Design eines Frameworks ist es – insbesondere für wenig etablierte Unternehmen – ratsam, „minimalinvasiv“ vorzugehen. Wenn Facebook oder Google einem Entwickler ein bestimmtes Design Pattern vorschreiben, wird er dieses grummelnd akzeptieren. Ob er dies auch bei weniger etablierten Playern macht, darf bezweifelt werden.

Schnelle Auslieferung

Eines der stärksten Verkaufsargumente für Gradle bzw. Android Studio ist mit Sicherheit die Möglichkeit, Bibliotheken durch Anpassen einer Datei in ein Projekt zu integrieren: Download und Co. erledigt der Build Daemon automatisch. Aus der Logik folgt, dass das hauseigene API – wann immer aus lizenzrechtlichen Gründen möglich – über den Bibliotheksmanager der meistverwendeten Programmierumgebung der Zielgruppe bereitgestellt werden sollte. Wer seine Android-Bibliothek also nicht im Gradle Repository hostet, muss sich über langsamere Adaption n...

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