Оглавление
John Ousterhout. Prinzipien des Softwaredesigns
Prinzipien des Softwaredesigns
Inhalt
Vorwort
KAPITEL 1. Einführung (es geht immer um Komplexität)
Wie Sie dieses Buch einsetzen
KAPITEL 2. Die Natur der Komplexität
Definition der Komplexität
Symptome der Komplexität
Ursachen für Komplexität
Komplexität ist inkrementell
Zusammenfassung
KAPITEL 3. Funktionierender Code reicht nicht aus (strategische versus taktische Programmierung)
Taktische Programmierung
Strategische Programmierung
Wie viel soll ich investieren?
Start-ups und Investitionen
Zusammenfassung
KAPITEL 4. Module sollten tief sein
Modulares Design
Was ist eine Schnittstelle?
Abstraktionen
Tiefe Module
Flache Module
Klassizitis
Beispiele: Java und Unix-I/O
Zusammenfassung
KAPITEL 5. Information Hiding (und Lecks)
Information Hiding
Informationslecks
Zeitliche Dekomposition
Beispiel: HTTP-Server
Beispiel: Zu viele Klassen
Beispiel: HTTP-Parameter-Handling
Beispiel: Standardwerte in HTTP-Responses
Information Hiding in einer Klasse
Wann Sie zu weit gehen
Zusammenfassung
KAPITEL 6. Vielseitige Module sind tiefer
Gestalten Sie Klassen halbwegs vielseitig
Beispiel: Text für einen Editor speichern
Eine vielseitigere API
Vielseitigkeit führt zu besserem Information Hiding
Fragen, die Sie sich stellen sollten
Spezialisierung nach oben (und unten!) schieben
Beispiel: Undo-Mechanismus für den Editor
Spezialfälle wegdesignen
Zusammenfassung
KAPITEL 7. Verschiedene Schichten, verschiedene Abstraktionen
Pass-Through-Methoden
Wann ist es in Ordnung, Schnittstellen doppelt zu haben?
Das Decorator-Design-Pattern
Schnittstelle versus Implementierung
Pass-Through-Variablen
Zusammenfassung
KAPITEL 8. Komplexität nach unten ziehen
Beispiel: Texteditor-Klasse
Beispiel: Konfigurationsparameter
Wann Sie zu weit gehen
Zusammenfassung
KAPITEL 9. Zusammen oder getrennt?
Zusammenbringen bei gemeinsamen Informationen
Zusammenbringen, um die Schnittstelle zu vereinfachen
Zusammenbringen, um doppelten Code zu vermeiden
Trennen von allgemeinem und speziellem Code
Beispiel: Einfügecursor und Auswahl
Beispiel: Getrennte Klasse zum Loggen
Methoden aufteilen und zusammenführen
Eine andere Meinung: Clean Code
Zusammenfassung
KAPITEL 10. Definieren Sie die Existenz von Fehlern weg
Warum Exceptions zur Komplexität beitragen
Zu viele Exceptions
Die Existenz von Fehlern wegdefinieren
Beispiel: Datei löschen in Windows
Beispiel: substring-Methode in Java
Exceptions maskieren
Aggregieren von Exceptions
Einfach abstürzen?
Wann Sie zu weit gehen
Zusammenfassung
KAPITEL 11. Designen Sie zweimal
KAPITEL 12. Warum Kommentare schreiben? – Die vier Ausreden
Guter Code dokumentiert sich selbst
Ich habe keine Zeit, Kommentare zu schreiben
Kommentare veralten und sind dann irreführend
Die Kommentare, die ich gesehen habe, sind alle nutzlos
Die Vorteile gut geschriebener Kommentare
Eine andere Meinung: Kommentare sind Fehler
KAPITEL 13. Kommentare sollten Dinge beschreiben, die im Code nicht offensichtlich sind
Konventionen
Wiederholen Sie nicht den Code
Kommentare auf niedrigerer Ebene sorgen für Präzision
Kommentare auf höherer Ebene verbessern die Intuition
Schnittstellendokumentation
Implementierungskommentare: was und warum, nicht wie
Modulübergreifende Designentscheidungen
Zusammenfassung
Antworten auf die Fragen aus dem Abschnitt »Schnittstellendokumentation« auf Seite 123
KAPITEL 14. Namen auswählen
Beispiel: Schlechte Namen führen zu Fehlern
Ein Bild schaffen
Namen sollten präzise sein
Namen konsistent einsetzen
Vermeiden Sie überflüssige Wörter
Eine andere Meinung: Go Style Guide
Zusammenfassung
KAPITEL 15. Erst die Kommentare schreiben (nutzen Sie Kommentare als Teil des Designprozesses)
Aufgeschobene Kommentare sind schlechte Kommentare
Erst die Kommentare schreiben
Kommentare sind ein Designwerkzeug
Frühes Kommentieren macht Spaß
Sind frühe Kommentare teuer?
Zusammenfassung
KAPITEL 16. Bestehenden Code anpassen
Bleiben Sie strategisch
Kommentare pflegen: Halten Sie die Kommentare nahe am Code
Kommentare gehören in den Code, nicht in das Commit-Log
Kommentare pflegen: Vermeiden Sie Duplikate
Kommentare pflegen: Schauen Sie auf die Diffs
Kommentare auf höherer Ebene lassen sich leichter pflegen
KAPITEL 17. Konsistenz
Beispiele für Konsistenz
Konsistenz sicherstellen
Wann Sie zu weit gehen
Zusammenfassung
KAPITEL 18. Code sollte offensichtlich sein
Dinge, die Code offensichtlicher machen
Dinge, die Code weniger offensichtlich machen
Zusammenfassung
KAPITEL 19. Softwaretrends
Objektorientierte Programmierung und Vererbung
Agile Entwicklung
Unit Tests
Test-Driven Development
Design Patterns
Getter und Setter
Zusammenfassung
KAPITEL 20. Performance
Wie man über Performance nachdenkt
Vor (und nach) dem Ändern messen
Rund um den kritischen Pfad designen
Ein Beispiel: RAMCloud-Buffer
Zusammenfassung
KAPITEL 21. Entscheiden, was wichtig ist
Wie entscheidet man, was wichtig ist?
Lassen Sie möglichst wenig wichtig sein
Wie Sie wichtige Dinge hervorheben
Fehler
Denken Sie umfassender
KAPITEL 22. Zusammenfassung
Fußnoten. KAPITEL 4 Module sollten tief sein
KAPITEL 5 Information Hiding (und Lecks)
KAPITEL 10 Definieren Sie die Existenz von Fehlern weg
KAPITEL 14 Namen auswählen
Index
Über den Autor
Kolophon
