Analiza i projektowanie obiektowe. Rusz głową!

Spis treści
Wprowadzenie
	Dla kogo jest ta książka?
	Wiemy, co sobie myślisz
	Metapoznanie: myślenie o myśleniu
	Ważne uwagi
	Zespół techniczny
	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
	Analiza metody search()
	Stosuj proste zasady projektowania obiektowego
	Projekt po raz pierwszy, projekt po raz drugi
	Jak łatwo można wprowadzać zmiany w Twojej aplikacji?
	Poddawaj hermetyzacji to, co się zmienia
	Delegowanie
	Nareszcie doskonałe opgrogramowanie (jak na razie)
	OOA&D ma na celu tworzenie wspaniałego oprogramowania, a nie dodanie Ci papierkowej roboty!
	Celne spostrzeżenia
2. Daj im to, czego chcą
	Nadszedł czas na kolejny pokaz Twych programistycznych umiejętności
	Test programu
	Nieprawidłowe zastosowanie (cos 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 przypadku 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żką oryginalną? Ścieżką alternatywną? 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
	Celne spostrzeżenia
5. (Część 1.) Nic nie pozostaje wiecznie takie samo
	Firma 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 zmodyfikować aplikacje 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 problemó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
	Przpadki 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
	Celne spostrzeżenia
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
	Celne spostrzeżenia
	Przybornik projektanta
9. Oprogramowanie jest wciąż przeznaczone dla klienta
	Twój przybornik narzędziowy powoli się wypełnia
	Wspaniałe opgrogramowanie 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
	Celne spostrzeżenia
	Przybornik projektanta
10. Scalając to wszystko w jedno
	Tworzenie oprogramowania w stylu obiektowym
	Trans-Obiektów
	Mapa metra w 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
	Celne spostrzeżenia