packages-api-konzept

Packages/API

Kurz: Ein Package ist ein Namensraum, der zusammengehörige Klassen gruppiert; eine API (Application Programming Interface) ist die Menge der öffentlich nutzbaren Klassen, Methoden und Funktionen, die eine Bibliothek oder ein System nach außen anbietet.

Genauer: Packages verhindern Namenskollisionen (zwei Klassen können denselben Namen tragen, wenn sie in unterschiedlichen Packages liegen) und strukturieren größere Projekte thematisch. Eine API definiert die “Vertragsschnittstelle” zu einem System — wie man es benutzt, ohne die interne Implementierung zu kennen — und ist damit eng mit dem Konzept der Abstraktion verwandt.

Im Detail

Ein Package ist im Grunde ein Ordner mit Bedeutung: Es gruppiert zusammengehörige Klassen und macht den vollständigen, eindeutigen Namen einer Klasse zu einer Kombination aus Package-Pfad und Klassennamen:

package de.emzett.wiki.models;
 
public class Artikel { ... }
// voller Name: de.emzett.wiki.models.Artikel

So können zwei völlig unterschiedliche Bibliotheken jeweils eine Klasse namens User definieren, ohne dass es zu einem Konflikt kommt, solange sie in unterschiedlichen Packages liegen (com.firma1.User vs. com.firma2.User) — der volle, qualifizierte Name ist immer eindeutig, auch wenn der kurze Klassenname mehrfach vorkommt.

Eine API (Application Programming Interface) ist dagegen kein technisches Sprachmittel, sondern ein Design-Konzept: die bewusst gewählte, öffentlich zugängliche “Oberfläche” eines Systems, über die andere Programme/Entwickler damit interagieren dürfen — alles, was NICHT Teil dieser API ist (interne Hilfsklassen, private Implementierungsdetails), gilt als Implementierungsdetail, das sich jederzeit ändern kann, ohne dass Nutzer der API davon betroffen sein sollten. Diese Trennung ist eine praktische Anwendung von Kapselung auf Projekt- statt auf Klassenebene.

Eine gut designte API zeichnet sich vor allem durch Stabilität aus: Einmal veröffentlichte öffentliche Methoden sollten möglichst nicht mehr in einer Weise geändert werden, die bestehenden Nutzercode bricht — größere APIs verwenden dafür oft Versionsnummern (z. B. Semantic Versioning) und markieren veraltete Teile als “deprecated”, statt sie abrupt zu entfernen, um Nutzern Zeit zur Anpassung zu geben.

Siehe auch: Classes, Abstraction, Interface