O'Reilly logo

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Objektorientierte Analyse & Design von Kopf bis Fuß

Book Description

Kluge Bücher über Objektorientierte Analyse & Design gibt es viele. Leider versteht man die meisten erst, wenn man selbst schon Profi-Entwickler ist... Und was machen all die Normalsterblichen, die natürlich davon gehört haben, dass OOA&D dazu beiträgt, k

Table of Contents

  1. Copyright
  2. Widmung
  3. Die Autoren
  4. Der Übersetzer
  5. Einführung
  6. Sauber entworfene Anwendungen rocken
    1. Rock 'n' Roll ist unsterblich!
    2. Ricks brandneue Anwendung ...
    3. So sieht der Code für Gitarre.java aus
    4. Und Bestand.java ...
    5. Aber dann begann Rick, Kunden zu verlieren ...
    6. Was würden Sie als ERSTES ändern?
    7. Gute Software hat ... nicht nur eine Definition
    8. Gute Software in 3 leichten Schritten
    9. Erinnern Sie sich an Rick und die verlorenen Kunden?
    10. Die String-Vergleiche über Bord werfen
    11. Ricks Kunden wollen Auswahl!
    12. Testlauf
    13. Zurück zu unseren Schritten
    14. Nach Problemen suchen
    15. Die Methode suchen() analysieren
    16. Aktualisieren Sie jetzt Ihren Code
    17. Die Klasse Bestand aktualisieren
    18. Vorbereitungen für einen weiteren Testlauf
    19. Zurück zu Ricks Anwendung ...
    20. Einmal entwerfen, zweimal entwerfen
    21. Stellen wir sicher, dass Bestand.java (wirklich) sauber entworfen ist
    22. Ein letzter Testlauf (und eine wiederverwendbare Anwendung)
    23. Was wir gemacht haben
    24. Erinnern Sie sich an diesen armen Typen
    25. Bei OOA&D geht es darum, gute Software zu schreiben, nicht um eine Menge Papierkram.
  7. Andforderungen sammelen
    1. Sie haben einen neuen Programmierauftrag
    2. Beginnen wir mit der Hundetür
    3. Testlauf
    4. Was genau ist eine Anforderung überhaupt?
    5. Hören Sie auf den Kunden
    6. Eine Anforderungsliste erstellen
    7. Davon ausgehen, dass etwas schiefgeht
    8. Alternativpfade zur Behandlung von Systemproblemen
    9. (Wieder-)Einführung von Anwendungsfällen
    10. Ein Anwendungsfall, drei Teile
    11. Ihre Anforderungen mit Ihrem Anwendungsfall vergleichen
    12. Ihr System muss im wahren Leben funktionieren ...
    13. Ihr OOA&D-Werkzeugkasten
  8. Anforderungen ändern sich
    1. Sie sind ein Held!
    2. Aber dann klingelt das Telefon ...
    3. Zurück ans Reißbrett
    4. Die Konstante bei Softwareanalyse und -design*
    5. Optionale Pfade? Alternative Pfade? Wer weiß das schon?
    6. Sie müssen den Anwendungsfall verstehen
    7. Vom Start zum Ziel: ein bestimmtes Szenario
    8. Machen Sie sich programmierbereit ...
    9. Die Anforderungsliste aufmöbeln
    10. Jetzt können wir wieder mit der Programmierung der Tür beginnen
    11. Hab ich da ein »wuff« gehört?
    12. Die neue Hundetür einschalten
    13. Die Hundetür aktualisieren
    14. Die Fernsteuerung vereinfachen
    15. Ein letzter Testlauf
    16. Ihr erweiterter OOA&D-Werkzeugkasten
  9. Analyse
    1. Ein Hund, zwei Hunde, drei Hunde, vier ...
    2. Ihre Software hat einen Kontext
    3. Identifizieren Sie das Problem
    4. Planen Sie eine Lösung
    5. Aktualisieren Sie Ihren Anwendungsfall
    6. Die Geschichte der zwei Programmierer
    7. Bellen vergleichen
    8. Delegation in Max' Hundetür: ein gründlicher Blick
    9. Zurück zu Max, Ruben und dem MacBook Pro ...
    10. Maria hat das MacBook Pro gewonnen!
    11. Was hat Maria also anders gemacht?
    12. Achten Sie auf die Nomen in Ihrem Anwendungsfall
    13. Es geht nur um den Anwendungsfall
    14. Aber es gibt hier keine Klasse Bellen!
    15. Eins dieser Dinge ist nicht wie das andere ...
    16. Denken Sie daran: Achten Sie auf diese Nomen!
    17. Von einer guten Analyse zu guten Klassen ...
    18. Klassendiagramme sezieren
    19. Klassendiagramme sind nicht alles
  10. Gutes Design = flexible Softwar
    1. Ricks Gitarren Saiteninstrumente expandiert
    2. Klassendiagramme seziert (noch mal)
    3. »Was ist eine Schnittstelle?«
    4. »Was ist Kapselung?«
    5. »Was ist VERÄNDERUNG?«
  11. Gutes Design = flexible Software
    1. Zurück zu Ricks Suchwerkzeug
    2. Ein genauerer Blick auf die suchen()-Methode
    3. Die Vorteile unserer Analyse
    4. Ein genauerer Blick auf die Instrument-Klassen
    5. Aber in Klassen geht es eigentlich um Verhalten!
    6. Tod einer Designentscheidung
    7. Wandeln wir ein paar schlechte Designentscheidungen in gute um
    8. Ein weiteres Gespräch am Arbeitsplatz (und etwas Hilfe von Jana)
    9. »Doppel-Kapselung« in Ricks Software
    10. Die Instrumenteigenschaften dynamisch machen
    11. Die neuen Instrument- und InstrumentDaten-Klassen verwenden
    12. Ricks Anwendung fertigstellen: das Enum InstrumentTyp
    13. Aktualisieren wir Bestand ebenfalls
    14. Und siehe da: Ricks flexible Anwendung
    15. Aber funktioniert die Anwendung wirklich?
    16. Ricks sauber entworfene Software testen
    17. Rick hat funktionierende Software, sein Kunde hat drei Optionen:
    18. Herzig! Unsere Software lässt sich leicht ändern ... ... aber was ist mit dieser »kohäsiv«-Sache?
    19. Kohäsion und ein Grund für die Veränderlichkeit einer Klasse
    20. Ricks Software im Rückblick
    21. Wissen, wann man sagen sollte: »Gut ist gut genug!«
    22. OOA&D-Werkzeugkasten
  12. Die richtig großen Probleme lösen
    1. Es kommt nur darauf an, wie Sie das große Problem betrachten
    2. Die Dinge, die Sie bereits wissen ...
    3. Lösen wir mal ein GROSSES Problem!
    4. Wir brauchen noch viel mehr Informationen
    5. Kundengespräch
    6. Die Features ermitteln
    7. Aber was ist überhaupt ein Feature?
    8. Verwenden Sie Anwendungsfalldiagramme
    9. Der Kleine Akteur
    10. Akteure sind auch Menschen (gut, nicht immer)
    11. Anwendungsfalldiagramm ... passt! Features behandelt ... passt!
    12. Was genau haben wir gemacht?
    13. Bürogespräch
    14. Treiben wir etwas Domänenanalyse!
    15. Was die meisten anderen dem Kunden geben ...
    16. Was wir dem Kunden geben ...
    17. Jetzt teilen und erobern
    18. Vergessen Sie nicht, wer wirklich Ihr Kunde ist
    19. Was ist ein Entwurfsmuster?
    20. Sie kommen sich etwas verloren vor?
    21. Die Macht von OOA&D (und etwas gesunder Menschenverstand)
    22. Ihr OOA&D-Werkzeugkasten
  13. Architektur
    1. Fühlen Sie sich etwas erschlagen?
    2. Wir brauchen eine Architektur
    3. Beginnen wir mit der Funktionalität
    4. Die drei Fragen der Architektur
    5. Jetzt haben wir viel weniger Chaos ...
    6. ... aber es gibt immer noch eine Menge zu tun
    7. Die Klassen Feld und Einheit
    8. Den richtigen Fokus behalten
    9. Mehr Ordnung, weniger Chaos
    10. An welchem Feature sollten wir jetzt arbeiten?
    11. Spielspezifische Einheiten ... was soll das heißen?
    12. Zurück zur Kommunalität
    13. Lösung 1: Alles ist verschieden!
    14. Lösung 2: Es ist alles gleich!
    15. Kommunalitätsanalyse: der Weg zu flexibler Software
    16. Und noch mehr Ordnung...
    17. Was bedeutet das? Fragen Sie den Kunden.
    18. Wissen Sie, was »Bewegungs-koordination« bedeutet?
    19. Gibt es hier irgendetwas Gemeinsames?
    20. Es ist »bei jedem Spiel anders«
    21. Risikoreduzierung hilft, gute Software zu schreiben
  14. Design-Prinzipien
    1. Design-Prinzip-Zusammenfassung
    2. Prinzip 1: Das Offen-Geschlossen-Prinzip (OCP)
    3. Erinnern Sie sich an die Arbeit an Ricks Saiteninstrumenten?
    4. Das OCP, Schritt für Schritt
    5. Prinzip 2:Das Meiden-Sie-Wiederholung-Prinzip (DRY)
    6. Bei DRY geht es um EINE Anforderung an EINEM Ort
    7. Prinzip 3: Das Prinzip der einen Verantwortlichkeit (SRP)
    8. Mehrere Verantwortlichkeiten aufspüren
    9. Von mehreren Verantwortlichkeiten zu einer Verantwortlichkeit übergehen
    10. Bewerber 4: Das Liskovsche Substitutionsprinzip (LSP)
    11. Vererbung missbrauchen: eine Fallstudie zu falschen Subklassen
    12. Das LSP zeigt verborgene Probleme mit unseren Vererbungsstrukturen auf
    13. »Subtypen müssen ihre Basistypen vertreten können«
    14. Verletzungen des LSP sorgen für verwirrenden Code
    15. Das 3DSpielbrett-Problem ohne Vererbung lösen
    16. Funktionalität an eine andere Klasse delegieren
    17. Wann Delegation verwendet werden sollte
    18. Nutzen Sie Komposition, um Verhalten von anderen Klassen zu sammeln
    19. Wann Sie Komposition ver wenden sollten
    20. Wenn die Pizza weg ist, sind e s auch die Zutaten ...
    21. Aggregation: Komposition ohne das plötzliche Ende
    22. Aggregation vs. Komposition
    23. Vererbung ist nur eine Option
    24. Ihr OOA&D-Werkzeugkasten
  15. Iteration und Tests
    1. Ihr Werkzeugkasten füllt sich
    2. Aber Sie schreiben immer noch Software für den KUNDEN!
    3. Tiefer iterieren: zwei Grundoptionen
    4. Feature-gesteuerte Entwicklung
    5. Anwendungsfall-gesteuerte Entwicklung
    6. Zwei Verfahren zur Entwicklung
    7. Nutzen wir Feature- gesteuerte Entwicklung
    8. Analyse eines Features
    9. Die Klasse Einheit ausarbeiten
    10. Die Klasse Einheit vorführen
    11. Testszenarien schreiben
    12. Lösung 1: Betonung der Kommunalität
    13. Lösung 2: Betonung der Kapselung
    14. Entscheiden wir uns für die kommunalitätsorientierte Lösung
    15. Bilden Sie Ihre Tests auf Ihr Design ab
    16. Schreiben wir die Klasse Einheit
    17. Sich dem Kunden stellen
    18. Wir haben auch bisher kontraktbasiert programmiert
    19. Das ist der Kontrakt für Einheit
    20. Bei der kontraktbasierten Programmierung geht es eigentlich um Vertrauen
    21. Aber wenn Sie Ihren Nutzern nicht trauen ...
    22. ... oder diese Ihnen nicht trauen ...
    23. Einheiten bewegen
    24. Sind wir hier nicht schon einmal gewesen?
    25. Brechen Sie Ihre Anwendungen in kleinere Happen Funktionalität auf
    26. Ihr OOA&D-Werkzeugkasten
  16. Der OOA&D-Lebenszyklus
    1. Software auf OOA&D-Art entwickeln
    2. Das Problem
    3. U-Bahn-Plan Objekthausen
    4. Jetzt sollten Sie wirklich wissen, was Sie tun müssen
    5. Anwendungsfälle spiegeln die Verwendung, Features spiegeln die Funktionalität
    6. Beginnen Sie jetzt die Iteration
    7. Ein genauerer Blick auf die Darstellung einer U-Bahn
    8. Sehen wir uns diese U-Bahn-Datei an
    9. Schauen wir, ob unser Anwendungsfall funktioniert
    10. Eine Linie-Klasse verwenden oder keine Linie-Klasse verwenden ... das ist hier die Frage
    11. Schreiben Sie die Klasse Haltestelle
    12. Die Klasse UBahn schreiben
    13. Sehenswürdigkeiten in der Objekthausener U-Bahn (Klasse)
    14. Ihre Klassen schützen (und die Ihres Kunden auch)
    15. Die Klasse UBahnLader
    16. Es ist Zeit, wieder zu iterieren
    17. Aber bevor wir mit Iteration 2 beginnen ...
    18. Was bleibt zu tun?
    19. Zurück zur Anforderungsphase ...
    20. Blicken Sie auf den Code, blicken Sie auf den Kunden ...
    21. Iteration vereinfacht Probleme
    22. Implementierung: UBahn.java
    23. Wie sieht eine Route aus?
    24. Eine letzte Testklasse ...
    25. Schauen Sie sich Objekthausen selbst an!
    26. Iteration 3 gefällig?
    27. Die Reise ist noch nicht zu Ende ...
  17. Was übrig bleibt
    1. 1. IST-EIN und HAT-EIN
    2. 2. Anwendungsfallformate
    3. 3. Anti-Muster
    4. 4. CRC-Karten
    5. 5. Metriken
    6. 6. Sequenzdiagramme
    7. 7. Zustandsdiagramme
    8. 8. Unit-Tests
    9. 9. Coding-Standards und lesbarer Code
    10. 10. Refactoring
  18. Anleitung für Objekthausen
    1. Willkommen in Objekthausen
    2. UML und Klassendiagramme
    3. Nächste Stufe: Vererbung
    4. Und auch Polymorphie ...
    5. Und zum Abschluss: Kapselung
    6. Jetzt kann jeder geschwindigkeit direkt setzen
    7. Was soll also das Problem sein?