Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalist - Helion
MIEJSCE 50 na liście TOP 20
Autor: Robert C. MartinTytuł oryginału: Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)
Tłumaczenie: Wojciech Moch
ISBN: 978-83-283-9109-3
stron: 376, Format: 170x230, okładka: mi
Data wydania: 2018-05-11
Księgarnia: Helion
Cena książki: 53,40 zł (poprzednio: 89,00 zł)
Oszczędzasz: 40% (-35,60 zł)
Osoby które kupowały "Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalist", wybierały także:
- Superinteligencja. Scenariusze, strategie, zagro 66,19 zł, (13,90 zł -79%)
- Poradnik design thinking - czyli jak wykorzysta 49,64 zł, (13,90 zł -72%)
- Kosymulacja. Elastyczne projektowanie i symulacja wielodomenowa 38,39 zł, (11,90 zł -69%)
- Testowanie kodu w praktyce 57,74 zł, (17,90 zł -69%)
- F# 4.0 dla zaawansowanych. Wydanie IV 96,45 zł, (29,90 zł -69%)
Spis treści
Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów -- spis treści
- Przedmowa
- Wstęp
- Podziękowania
- O autorze
- I Wprowadzenie
- 1. Czym są projekt i architektura?
- Cel?
- Studium przypadku
- Oznaki bałaganu
- Okiem zarządu
- Gdzie szukać przyczyny?
- Wnioski
- 2. Opowieść o dwóch wartościach
- Zachowanie
- Architektura
- Ważniejsza wartość
- Macierz Eisenhowera
- Walka o architekturę
- II Zacznij od podstaw. Paradygmaty oprogramowania
- 3. Przegląd paradygmatów
- Programowanie strukturalne
- Programowanie obiektowe
- Programowanie funkcyjne
- Coś do przemyślenia
- Wnioski
- 4. Programowanie strukturalne
- Dowód
- Ogłoszenie szkodliwości
- Dekompozycja funkcyjna
- Brak formalnych dowodów
- Metoda naukowa
- Testy
- Wnioski
- 5. Programowanie obiektowe
- Hermetyzacja?
- Dziedziczenie?
- Polimorfizm?
- Moc polimorfizmu
- Odwrócenie zależności
- Wnioski
- 6. Programowanie funkcyjne
- Kwadraty liczb całkowitych
- Niezmienność i architektura
- Podział zmienności
- Strumień zdarzeń
- Wnioski
- III Reguły projektowe
- 7. SRP reguła jednej odpowiedzialności
- Symptom 1. Przypadkowa duplikacja
- Symptom 2. Złączenia
- Rozwiązania
- Wnioski
- 8. Reguła otwarte-zamknięte
- Eksperyment myślowy
- Kontrola kierunku
- Ukrywanie informacji
- Wnioski
- 9. Zasada podstawień Barbary Liskov
- Jak używać dziedziczenia?
- Problem z kwadratem i prostokątem
- Zasada LSP i architektura
- Przykład naruszenia zasady LSP
- Wnioski
- 10. Zasada rozdzielania interfejsów
- Zasada ISP i język
- Zasada ISP i architektura
- Wnioski
- 11. Zasada odwrócenia zależności
- Stabilne abstrakcje
- Fabryki
- Komponenty konkretne
- Wnioski
- IV Zasady komponentów
- 12. Komponenty
- Krótka historia komponentów
- Relokacje
- Konsolidatory
- Wnioski
- 13. Spójność komponentów
- Zasada Reuse (Release Equivalence Principle)
- Zasada Common Closure Principle
- Podobieństwo do zasady SRP
- Zasada Common Reuse Principle
- Związki z zasadą ISP
- Diagram napięć dla zasad spójności komponentów
- Wnioski
- 14. Łączenie komponentów
- Zasada zależności niecyklicznych
- Cotygodniowa kompilacja
- Eliminowanie zależności cyklicznych
- Efekty powstania cykli w grafie zależności komponentów
- Usuwanie cykli
- Drgania
- Projekt typu top-down
- Zasada stabilnych zależności
- Stabilność
- Miara stabilności
- Nie wszystkie komponenty powinny być stabilne
- Komponenty abstrakcyjne
- Zasada stabilnych abstrakcji
- Gdzie umieścić reguły wysokiego poziomu?
- Wprowadzenie do zasady stabilnych abstrakcji
- Miara abstrakcji
- Ciąg główny
- Strefa bólu
- Strefa bezużyteczności
- Unikanie stref wykluczenia
- Odległość od ciągu głównego
- Wnioski
- Zasada zależności niecyklicznych
- V Architektura
- 15. Czym jest architektura?
- Rozwój systemu
- Wdrożenia
- Działanie
- Konserwacja
- Zachowywanie dostępnych opcji
- Niezależność od urządzenia
- Spam
- Adresowanie fizyczne
- Wnioski
- 16. Niezależność
- Przypadki użycia
- Działanie
- Rozwój
- Wdrożenia
- Otwarte opcje
- Oddzielanie warstw
- Rozdzielanie przypadków użycia
- Tryby rozdzielania
- Możliwość niezależnego rozwijania
- Niezależne wdrożenia
- Duplikacja
- Tryby rozdzielania (ponownie)
- Wnioski
- 17. Granice. Wyznaczanie linii
- Dwie smutne historie
- FitNesse
- Jakie linie rysować i kiedy to robić?
- A co z wejściem i wyjściem?
- Architektura wtyczek
- A jednak wtyczki
- Wnioski
- 18. Anatomia granic
- Przekraczanie granic
- Straszliwy monolit
- Instalowanie komponentów
- Wątki
- Procesy lokalne
- Usługi
- Wnioski
- 19. Zasady i poziomy
- Poziomy
- Wnioski
- 20. Reguły biznesowe
- Encje
- Przypadki użycia
- Modele żądania i odpowiedzi
- Wnioski
- 21. Krzycząca architektura
- Motyw architektury
- Cel architektury
- A co z siecią WWW?
- Framework to narzędzie, a nie styl życia
- Testowanie architektury
- Wnioski
- 22. Czysta architektura
- Zasada zależności
- Encje
- Przypadki użycia
- Adaptery interfejsów
- Frameworki i sterowniki
- Tylko cztery kręgi?
- Przekraczanie granic
- Jakie dane przekraczają granice?
- Typowy scenariusz
- Wnioski
- Zasada zależności
- 23. Prezentery i skromne obiekty
- Wzorzec projektowy skromny obiekt
- Prezentery i widoki
- Testowanie i architektura
- Bramy do baz danych
- Mapowanie danych
- Serwisy
- Wnioski
- 24. Granice częściowe
- Pomiń ostatni krok
- Granice jednowymiarowe
- Fasady
- Wnioski
- 25. Warstwy i granice
- Hunt the Wumpus
- Czysta architektura?
- Przekraczanie strumieni
- Dzielenie strumieni
- Wnioski
- 26. Komponent Main
- Najważniejszy detal
- Wnioski
- 27. Serwisy, duże i małe
- Architektura serwisów?
- Zalety serwisów?
- Czy rzeczywiście separują?
- Czy rzeczywiście pozwalają na niezależny rozwój i wdrożenia?
- Problem z kotkami
- Pomogą nam obiekty
- Serwisy bazujące na komponentach
- Sprawy ogólnosystemowe
- Wnioski
- 28. Granice testów
- Testy jako komponenty systemu
- Projekt ułatwiający testy
- API testujące
- Rozdzielanie strukturalne
- Bezpieczeństwo
- Wnioski
- 29. Czysta architektura osadzona
- Test n-App-stawienia
- Problem docelowego sprzętu
- Czysta architektura osadzona umożliwia testowanie
- Warstwy
- Sprzęt jest szczegółem
- Nie przekazuj szczegółów sprzętowych użytkownikom warstwy HAL
- Procesor jest szczegółem
- System operacyjny jest szczegółem
- Programowanie dla interfejsów i możliwości podmiany
- Warunkowe dyrektywy kompilatora i zasada DRY
- Czysta architektura osadzona umożliwia testowanie
- Wnioski
- VI Szczegóły
- 30. Baza danych jest szczegółem
- Relacyjne bazy danych
- Dlaczego systemy baz danych są takie powszechne?
- A gdyby nie było dysków?
- Szczegóły
- A co z wydajnością?
- Anegdota
- Wnioski
- 31. Sieć WWW jest szczegółem
- Wieczne wahadło
- Rezultat
- Wnioski
- 32. Frameworki są szczegółem
- Autorzy frameworków
- Małżeństwo asymetryczne
- Ryzyko
- Rozwiązanie
- Teraz ogłaszam was
- Wnioski
- 33. Studium przypadku. Sprzedaż filmów
- Produkt
- Analiza przypadków użycia
- Architektura komponentów
- Zarządzanie zależnościami
- Wnioski
- 34. Zaginiony rozdział
- Pakowanie w warstwy
- Pakowanie według funkcji
- Porty i adaptery
- Pakowanie według komponentów
- Diabeł tkwi w szczegółach implementacji
- Organizacja a hermetyzacja
- Inne sposoby rozdzielania
- Wnioski. Zaginiona porada
- VII Dodatki
- A Archeologia architektury
- System księgowości Union
- Cięcie laserowe
- Monitorowanie odlewów aluminium
- 4-TEL
- Komputer SAC
- Wysyłanie serwisantów
- Architektura
- Wielkie przeprojektowanie
- Europa
- Wnioski
- Język C
- C
- BOSS
- pCCU
- Pomyłka w planach
- DLU/DRU
- Architektura
- VRS
- Nazwa
- Architektura
- Wnioski
- Elektroniczny recepcjonista
- Śmierć recepcjonisty
- System wysyłania serwisantów
- Clear Communications
- Wstęp
- Wujek Bob
- Telefon
- ROSE
- Nieustające dyskusje
- pod innymi nazwami
- Egzamin na architekta
- Wnioski
- Posłowie