Spis treści
Wprowadzenie
Dla kogo jest ta książka?
Wiemy, co sobie myślisz
Metapoznanie: myślenie o myśleniu
Zmuś swój mózg do posłuszeństwa
Ważne uwagi
Recenzenci techniczni
Podziękowania
1. Tu się zaczyna wspaniałe oprogramowanie
Rock-and-roll jest wieczny!
Nowa elegancka aplikacja Ryśka…
Co przede wszystkim zmieniłbyś w aplikacji Ryśka?
Doskonałe oprogramowanie… ma więcej niż jedną z wymienianych już cech
Wspaniałe oprogramowanie w trzech prostych krokach
W pierwszej kolejności skoncentruj się na funkcjonalności
Test
Szukamy problemów
Stosuj proste zasady projektowania obiektowego
Projekt po raz pierwszy, projekt po raz drugi
Jak łatwo można wprowadzić zmiany w Twojej aplikacji?
Poddawaj hermetyzacji to, co sie zmienia
Delegowanie
Nareszcie doskonałe oprogramowanie (jak na razie)
OOA&D ma na celu tworzenie wspaniałego oprogramowania, a nie dodanie Ci papierkowej roboty!
Kluczowe zagadnienia
2. Daj im to, czego chcą
Nadszedł czas na kolejny pokaz Twych programistycznych umiejętności
Test programu
Nieprawidłowe zstosowanie (coś w tym stylu)
Czym jest wymaganie
Tworzenie listy wymagań
Zaplanuj, co może się popsuć w systemie
Problemy w działaniu systemu są obsługiwane przez ścieżki alternatywne
(Ponowne) przedstawienie przypadków użycia
Jeden przypadek użycia, trzy części
Porównaj wymagania z przypadkami użycia
Twój system musi działać w praktyce
Poznajemy Szczęśliwą Ścieżkę
Przybornik projektanta
3. Kocham cię, jesteś doskonały… A teraz — zmień się
Jesteś bohaterem!
Jesteś patałachem!
Jedyny pewnik analizy i projektowania obiektowego
Ścieżka oryginalna? Ścieżka alternatywna? Kto to wie?
Przypadki użycia muszą być zrozumiałe i użyteczne przede wszystkim dla Ciebie
Od startu do mety: jeden scenariusz
Wyznanie Ścieżki Alternatywnej
Uzupełnienie listy wymagań
Powielanie kodu jest bardzo złym pomysłem
Ostateczny test drzwiczek
Napisz swoją własną zasadę projektową!
Przybornik projektanta
4. Zaczynamy używać naszych aplikacji w rzeczywistym świecie
Jeden pies, dwa psy, trzy psy, cztery…
Twoje oprogramowanie ma kontekst
Określ przyczynę problemu
Zaplanuj rozwiązanie
Opowieść o dwóch programistach
Delegowanie w kodzie Szymka — analiza szczegółowa
Potęga aplikacji, których elementy są ze sobą luźno powiązane
Zwracaj uwagę na rzeczowniki występujące w przypadku użycia
Od dobrej analizy do dobrych klas…
Diagramy klas bez tajemnic
Diagramy klas to nie wszystko
Kluczowe zagadnienia
5. (część 1.) Nic nie pozostaje wiecznie takie samo
Firma Gitary/Instrumenty Strunowe Ryśka rozwija się
Klasy abstrakcyjne
Diagramy klas bez tajemnic (ponownie)
Ściągawka z UML-a
Porady dotyczące problemów projektowych
Trzy kroki tworzenia wspaniałego oprogramowania (po raz kolejny)
5. (przerywnik) Obiektowa katastrofa
5. (część 2.) Zabierz swoje oprogramowanie na 30-minutowy trening
Wróćmy do aplikacji wyszukiwawczej Ryśka
Dokładniejsza analiza metody search()
Korzyści, jakie dała nam analiza
Dokładniejsza analiza klas instrumentów
Śmierć projektu (decyzja)
Zmieńmy złe decyzje projektowe na dobre
Zastosowanie „podwójnej hermetyzacji” w aplikacji Ryśka
Nigdy nie obawiaj się wprowadzania zmian
Elastyczna aplikacja Ryśka
Testowanie dobrze zaprojektowanej aplikacji Ryśka
Jak łatwo można wprowadzać zmiany w aplikacji Ryśka?
Wielki konkurs łatwości modyfikacji
Spójna klasa realizuje jedną operację naprawdę dobrze
Przegląd zmian wprowadzonych w oprogramowaniu dla Ryśka
Doskonałe oprogramowanie to zazwyczaj takie, które jest „wystarczająco dobre"
Przybornik projektanta
6. „Nazywam się Art Vandelay… jestem Architektem”
Rozwiązywanie dużych probleów
Wszystko zależy od sposobu spojrzenia na duży problem
Wymagania i przypadki użycia to dobry punkt wyjściowy...
Potrzebujemy znacznie więcej informacji
Określanie możliwości
Możliwość czy wymaganie
Przypadki użycia nie zawsze pomagają ujrzeć ogólny obraz tworzonego oprogramowania
Diagramy przypadków użycia
Mały aktor
Aktorzy to także ludzie (no dobrze… nie zawsze)
A zatem zabawmy się w analizę dziedziny!
Dziel i rządź
Nie zapominaj, kim tak naprawdę jest klient
Czym jest wzorzec projektowy?
Potęga OOA&D (i trochę zdrowego rozsądku)
Przybornik projektanta
7. Porządkowanie chaosu
Czy czujesz się nieco przytłoczony?
Potrzebujemy architektury
Zacznijmy od funkcjonalności
Co ma znaczenie dla architektury
Trzy „P” dotyczące architektury
Wszystko sprowadza się do problemu ryzyka
Scenariusze pomagają zredukować ryzyko
Koncentruj się na jednej możliwości w danej chwili
Architektura jest strukturą Twojego projektu
Podobieństwa po raz kolejny
Analiza podobieństw: ścieżka do elastycznego oprogramowania
Co to znaczy? Zapytaj klienta
Zmniejszanie ryzyka pomaga pisać wspaniałe oprogramowanie
Kluczowe zagadnienia
8. Oryginalność jest przereklamowana
Zasada projektowania — w skrócie
Zasada otwarte-zamknięte
OCP, krok po kroku
Zasada nie powtarzaj się
Zasada DRY dotyczy obsługi JEDNEGO wymagania w JEDNYM miejscu
Zasada jednej odpowiedzialności
Wykrywanie wielu odpowiedzialności
Przechodzenie od wielu do jednej odpowiedzialności
Zasada podstawienia Liskov
Studium błędnego sposobu korzystania z dziedziczenia
LSP ujawnia ukryte problemy związane ze strukturą dziedziczenia
Musi istnieć możliwość zastąpienia typu bazowego jego typem pochodnym
Naruszenia LSP sprawiają, że powstający kod staje się mylący
Deleguj funkcjonalność do innej klasy
Użyj kompozycji, by zebrać niezbędne zachowania z kilku innych klas
Agregacja — kompozycja bez nagłego zakończenia
Agregacja a kompozycja
Dziedziczenie jest jedynie jedną z możliwości
Kluczowe zagadnienia
Przybornik projektanta
9. Oprogramowanie jest wciąż przeznaczone dla klienta
Twój przybornik narzędziowy powoli się wypełnia
Wspaniałe oprogramowanie tworzy się iteracyjnie
Schodzenie w głąb: dwie proste opcje
Programowanie w oparciu o możliwości
Programowanie w oparciu o przypadki użycia
Dwa podejścia do tworzenia oprogramowania
Analiza możliwości
Pisanie scenariuszy testowych
Programowanie w oparciu o testy
Podobieństwa po raz wtóry
Kładziemy nacisk na podobieństwa
Hermetyzujemy wszystko
Dopasuj testy do projektu
Testy bez tajemnic…
Udowodnij klientowi, że wszystko idzie dobrze
Jak dotąd używaliśmy programowania w oparciu o kontrakt.
Tak naprawdę programowanie w oparciu o kontrakt dotyczy zaufania
Programowanie defensywne
Podziel swoją aplikację na mniejsze fragmenty funkcjonalności
Kluczowe zagadnienia
Przybornik projektanta
10. Scalając to wszystko w jedno
Tworzenie oprogramowania w stylu obiektowym
Trans-Obiektów
Mapa metra o Obiektowie
Lista możliwości
Przypadki użycia odpowiadają zastosowaniu, możliwości odpowiadają funkcjonalności
A teraz zacznij powtarzać te same czynności
Dokładniejsza analiza sposobu reprezentacji sieci metra
Używać klasy Line czy też nie używać… oto jest pytanie
Najważniejsze sprawy związane z klasą Subway
Ochrona własnych klas
Czas na przerwę
Wróćmy znowu do etapu określania wymagań…
Koncentruj się na kodzie, a potem na klientach
Powtarzanie sprawia, że problemy stają się łatwiejsze
Jak wygląda trasa?
Samemu sprawdź Przewodnik Komunikacyjny po Obiektowie
Ktoś chętny na trzeci cykl prac?
Podróż jeszcze nie dobiegła końca…
A. Dziesięć najważniejszych tematów (których nie poruszyliśmy)
Nr 1. JEST i MA
Nr 2. Sposoby zapisu przypadków użycia
Nr 3. Antywzorce
Nr 4. Karty CRC
Nr 5. Metryki
Nr 6. Diagramy sekwencji
Nr 7. Diagramy stanu
Nr 8. Testowanie jednostkowe
Nr 9. Standardy kodowania i czytelny kod
Nr 10. Refaktoryzacja
B. Stosowanie języka obiektowego
UML i diagramy klas
Dziedziczenie
Polimorfizm…
Hermetyzacja
Kluczowe zagadnienia
Skorowidz