JAX 08: API-Design - Entwurf stabiler und beständiger Schnittstellen

von Thomas Bahn,
assono GmbH, Standort Kiel,



Arno Haase, Sven Efftinge:
API-Design ? Entwurf stabiler und beständiger Schnittstellen

API - Application Programming Interface
SPI - Service Provider Interface -

Bestandteile eines Java-APIs

API-Bestandteile sprachabhängig

von schwache Typisierung (Ruby) bis
Design by Contract (Eiffel)


Weitere Bestandteile

Veröffentlichte Schnittstelle

Was ist ein gutes API?

Best Practices (Vorgehen)


Use Case-zentriert

Design aus Sicht des Clients

Gegengewicht zu Abstraktionen aus Sicht
der Bibliothek

Klare Abstraktionen

gute Abstraktionen sind

Domänenanalyse

Iterative Entwickung

Schnittstelle vor der Veröffentlichung
reifen lassen

Explizite Releases

Anders als "normaler" Code
hat ein API zwingend klare Releases

Vorab-Tests
sind möglich


Mut zur Lücke

Es gibt typischerweise Druck, schnell
zu veröffentlichen

Best Practices (Design)


Explizites API

Trennung von API und Implementierung

Einfaches API

Man kann APIs leicht erweitern, aber
schwer wieder Elemente entfernen

Einfach zu lernen

Einfach
zu pflegen und zu erweitern

Gute
Defaults

Facade

Convenience-Methoden
für häufig verwendete Aktionen

Checked Exceptions sinnvoll?


Einfachheit SPI

Ein Interface kann nicht erweitert werden!

Ein Interface sollte möglichst wenig
Methoden deklarieren

Trennung von API (nicht reduzierbar)
und SPI (nicht erweiterbar)

Anbieten einer abstrakten Defaultimplementierung


Überraschungsfreiheit

Unveränderliche Datentypen

Annahmen im Code explizit machen

Gute
Name wählen

Fehlbedienung zur Laufzeit melden

API-Separierung

Trennung eines großen APIs in überschaubare
Teile mit klarem Fokus

Beispiele

Best Practices (Implementierung)


Interfaces oder Klassen?


kein globaler Zustand

globaler Zustand verschleiert Abhängigkeiten

Unveränderlichkeit (Immutability)

Pro

Contra

Methoden statt Feldern

Methoden kapseln Implementierungsdetails

aber
nicht dogmatisch?


Factories

Factories kapseln Details der Erzeugung

Große Auswahl an Entwurfsmustern

Service-Repositories als Spezialfall

Verwendung explizit im Code

Java bietet Sprachmittel, um einen beabsichtigte
Verwendung im Quelltext explizit zu machen

Listener

Listener erlauben die Erweiterung eines
API an wohldefinierten Stellen

Klarer
Contract für Listener

API-Evolution: Problemstellung

APIs behindern die Evolutions der Bibliothek

Anforderungen ändern sich


Lebenszyklus von Schnittstellen

viergeteilter Lebenszyklus

SPI-Evoution

Möglichkeiten

Neues Interface für Änderung

Auswirkungen

Framework-Code

Typ abfragen und casten


Vererbungshierarchie von Interfaces

neue Interfaces erweitern die alten


Refactoring mit API-Bruch

aufräumen!

Fachbeitrag JavaScript Java Veranstaltung Sonstiges

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Sie wollen eine individuelle Lösung? Kontaktieren Sie uns

Weitere interessante Artikel

IBM Cognos Analytics 11.0.9 (R9)

IBM Cognos Analytics 11.0.9 (R9)

Erst Mitte November hatten wir über Neuerung in der Version 11.0.8 gebloggt. Knapp ein Monat später veröffentlicht IBM die Version 11.0.9 … Mehr

von
Filip Meyer
,

Sie haben Fragen? Wir sind für Sie da.

Wenn Sie mehr über unsere Angebote erfahren möchten, können Sie uns jederzeit kontaktieren. Sie können uns auf verschiedene Weisen für eine unverbindliche Erstberatung erreichen:

assono GmbH

Standort Kiel (Zentrale)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Standort Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Telefonnummern:
Zentrale: +49 4307 900 407
Techn. Hotline: +49 4307 900 403
Vertrieb: +49 4307 900 402

E-Mail-Adressen:
kontakt@assono.de
bewerbung@assono.de