Prinzipien des Softwaredesigns

Table of contents

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