reklama - zainteresowany?

Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalist - Helion

Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalist

MIEJSCE 50 na liście TOP 20
Autor: Robert C. Martin
Tytuł 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ł)

Dodaj do koszyka Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalist

Tagi: Inne - Programowanie | Techniki programowania

Pierwsze linie kodu powstawa

Dodaj do koszyka Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalist

 

Osoby które kupowały "Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalist", wybierały także:

  • Superinteligencja. Scenariusze, strategie, zagro
  • Poradnik design thinking - czyli jak wykorzysta
  • Kosymulacja. Elastyczne projektowanie i symulacja wielodomenowa
  • Testowanie kodu w praktyce
  • F# 4.0 dla zaawansowanych. Wydanie IV

Dodaj do koszyka Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalist

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
  • 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
  • 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
    • 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

Dodaj do koszyka Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalist

Code, Publish & WebDesing by CATALIST.com.pl



(c) 2005-2024 CATALIST agencja interaktywna, znaki firmowe należą do wydawnictwa Helion S.A.