Читать книгу Prinzipien des Softwaredesigns - John Ousterhout - Страница 5
Inhalt
Оглавление1Einführung (es geht immer um Komplexität)
3Funktionierender Code reicht nicht aus (strategische versus taktische Programmierung)
Wie viel soll ich investieren?
5Information Hiding (und Lecks)
Beispiel: HTTP-Parameter-Handling
Beispiel: Standardwerte in HTTP-Responses
Information Hiding in einer Klasse
6Vielseitige Module sind tiefer
Gestalten Sie Klassen halbwegs vielseitig
Beispiel: Text für einen Editor speichern
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
7Verschiedene Schichten, verschiedene Abstraktionen
Wann ist es in Ordnung, Schnittstellen doppelt zu haben?
Schnittstelle versus Implementierung
8Komplexität nach unten ziehen
Beispiel: Konfigurationsparameter
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
10Definieren Sie die Existenz von Fehlern weg
Warum Exceptions zur Komplexität beitragen
Die Existenz von Fehlern wegdefinieren
Beispiel: Datei löschen in Windows
Beispiel: substring-Methode in Java
12Warum 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
13Kommentare sollten Dinge beschreiben, die im Code nicht offensichtlich sind
Wiederholen Sie nicht den Code
Kommentare auf niedrigerer Ebene sorgen für Präzision
Kommentare auf höherer Ebene verbessern die Intuition
Implementierungskommentare: was und warum, nicht wie
Modulübergreifende Designentscheidungen
Antworten auf die Fragen aus dem Abschnitt »Schnittstellendokumentation« auf Seite 123
Beispiel: Schlechte Namen führen zu Fehlern
Vermeiden Sie überflüssige Wörter
Eine andere Meinung: Go Style Guide
15Erst die Kommentare schreiben (nutzen Sie Kommentare als Teil des Designprozesses)
Aufgeschobene Kommentare sind schlechte Kommentare
Kommentare sind ein Designwerkzeug
Frühes Kommentieren macht Spaß
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
18Code sollte offensichtlich sein
Dinge, die Code offensichtlicher machen
Dinge, die Code weniger offensichtlich machen
Objektorientierte Programmierung und Vererbung
Wie man über Performance nachdenkt
Vor (und nach) dem Ändern messen
Rund um den kritischen Pfad designen
21Entscheiden, was wichtig ist
Wie entscheidet man, was wichtig ist?
Lassen Sie möglichst wenig wichtig sein
