API-Design. Kai Spichale

       2.2.3Dokumentiert

       2.2.4Einprägsam und leicht zu lernen

       2.2.5Lesbaren Code fördernd

       2.2.6Schwer falsch zu benutzen

       2.2.7Minimal

       2.2.8Stabil

       2.2.9Einfach erweiterbar

       2.3Konnaszenz

       2.4Zusammenfassung

       3Allgemeines Vorgehen beim API-Design

       3.1Überblick

       3.2Heuristiken und Trade-offs

       3.3Anforderungen herausarbeiten

       3.4Wenn Use Cases nicht ausreichen

       3.5Entwurf mit Szenarien und Codebeispielen

       3.6Spezifikation erstellen

       3.7Reviews und Feedback

       3.8Wiederverwendung

       3.9Zusammenfassung

       Teil IIJava-APIs

       4Ausprägungen

       4.1Implizite Objekt-API

       4.2Utility-Bibliothek

       4.3Service

       4.4Framework

       4.5Eine Frage der Priorität

       4.6Zusammenfassung

       5Grundlagen für Java-APIs

       5.1Auswahl passender Namen

       5.1.1Klassennamen

       5.1.2Methodennamen

       5.1.3Parameternamen

       5.1.4Ubiquitäre Sprache

       5.1.5Fazit

       5.2Effektiver Einsatz von Typen

       5.2.1Semantischen Vertrag minimieren

       5.2.2Semantische Verletzung der Datenkapselung vermeiden

       5.2.3Werden Namen überschätzt?

       5.2.4Fazit

       5.3Techniken für Objektkollaboration

       5.3.1Tell, Don’t Ask

       5.3.2Command/Query Separation

       5.3.3Law of Demeter

       5.3.4Platzierung von Methoden

       5.3.5Fazit

       5.4Jigsaw-Module

       5.5Minimale Sichtbarkeit

       5.5.1Jigsaw-Module

       5.5.2Packages

       5.5.3Klassen

       5.5.4Methoden

       5.5.5Felder

       5.5.6Fazit

       5.6Optionale Hilfsmethoden

       5.6.1Komfort

       5.6.2Utility-Klassen

       5.6.3Fazit

       5.7Optionale Rückgabewerte

       5.7.1Ad-hoc-Fehlerbehandlung