Kooperativer Bibliotheksverbund

UID:

Umfang: 1 online resource (192 pages)

Ausgabe: 1

ISBN: 9783960104995

Serie: Animals

Anmerkung: Intro -- Inhalt -- 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 -- Index

Weitere Ausg.: Print version: Ousterhout, John Prinzipien des Softwaredesigns Heidelberg : o'Reilly,c2021 ISBN 9783960091592

Schlagwort(e): Electronic books.

URL: https://ebookcentral.proquest.com/lib/th-brandenburg/detail.action?docID=6800825

URL: https://static.onleihe.de/content/bookwire_nat/20211109/9783960104995/v9783960104995.pdf

URL: https://static.onleihe.de/images/bookwire_nat/20211109/9783960104995/tn9783960104995l.jpg

URL: https://voebb.onleihe.de/berlin/frontend/mediaInfo,51-0-1646278530-100-0-0-0-0-0-0-0.html