Swift Academy · Lekcja

Zasady projektowania zorientowanego na protokoły

Preferowanie kompozycji protokołów zamiast dziedziczenia klas w celu uzyskania elastycznego projektu.

Zasady projektowania zorientowanego na protokoły to bezpłatna lekcja Swift Academy na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Swift Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Swift Academy zawiera 4 lekcji w sumie.

Wprowadzenie

Programowanie zorientowane protokołowo (POP) preferuje składanie protokołów zamiast dziedziczenia po klasach, aby tworzyć elastyczny, łatwy do testowania i wielokrotnego użycia kod Swift.

Problem z dziedziczeniem

Głębokie hierarchie klas powodują kilka problemów: • Podklasy dziedziczą cały stan i całe zachowanie nadklasy • Zmiana nadklasy może zepsuć podklasy • Nie można dziedziczyć po dwóch klasach Protokoły rozwiązują wszystkie trzy problemy.

Rozpoczynanie od protokołu

```swift protocol Greetable { var greeting: String { get } func greet() } extension Greetable { func greet() { print(greeting) } // default implementation } ``` Rozszerzenia protokołów zapewniają implementacje domyślne, które każdy typ zgodny z protokołem otrzymuje bez dodatkowej pracy.

Składanie zachowań

```swift protocol Persistable { func save() } protocol Networked { func fetch() async throws -> Data } protocol Loggable { func log(_ msg: String) } struct DataService: Persistable, Networked, Loggable { ... } ``` Można łączyć zachowania niczym klocki LEGO — hierarchia klas nie jest potrzebna.

Rozszerzenia protokołów do współdzielenia logiki

```swift extension Loggable { func log(_ msg: String) { print("[\(type(of: self))] \(msg)") } } // Every Loggable type gets this for free ```

Retroaktywne modelowanie

Protokoły można stosować do typów, których nie jest się właścicielem: ```swift protocol JSONConvertible { func toJSON() -> String } extension Int: JSONConvertible { func toJSON() -> String { "\(self)" } } ``` Można dodawać zgodność ze standardowymi typami biblioteki bez tworzenia podklas.

Typy wartości i protokoły

Struktury zgodne z protokołami zapewniają zarówno semantykę wartości, *jak i* polimorfizm: ```swift protocol Shape { var area: Double { get } } struct Circle: Shape { var radius: Double; var area: Double { .pi * radius * radius } } struct Square: Shape { var side: Double; var area: Double { side * side } } let shapes: [any Shape] = [Circle(radius:3), Square(side:4)] shapes.map { $0.area } // [28.27, 16] ```

Wstrzykiwanie zależności za pomocą protokołu

```swift protocol DataStore { func save(_ data: Data) } struct FileStore: DataStore { func save(_ d: Data) { /* disk */ } } struct MockStore: DataStore { func save(_ d: Data) { /* test log */ } } class Service { let store: DataStore init(store: DataStore) { self.store = store } } ```

Kiedy używać klas

Klasy warto wybierać, gdy: • Potrzebny jest współdzielony, zmienny stan (semantyka referencji) • Wymagana jest integracja z interfejsami API ObjC/UIKit • Dziedziczenie jest właściwym modelem (co zdarza się rzadko) W pozostałych przypadkach należy domyślnie wybierać protokoły i struktury.

Konwencje nazewnicze protokołów

• Protokoły określające możliwości: przyrostki `-able`, `-ible`, `-ing` (Equatable, Hashable, Coding) • Protokoły delegatów: przyrostek `Delegate` lub `DataSource` • Abstrakcyjna rola: rzeczownik (`Store`, `Parser`, `Renderer`) Dobre nazwy sprawiają, że kod zorientowany protokołowo sam wyjaśnia swoje przeznaczenie.

Szybkie sprawdzenie

Co rozszerzenia protokołów zapewniają typom zgodnym z tymi protokołami?

Podsumowanie

Najważniejsze informacje: • Należy preferować protokoły i struktury zamiast hierarchii klas • Rozszerzenia protokołów zapewniają współdzielone implementacje domyślne • Zachowania należy składać z małych protokołów o jednym przeznaczeniu • Protokoły umożliwiają wstrzykiwanie zależności na potrzeby testowania • Klasy należy rezerwować dla semantyki referencji i współdziałania z ObjC Kurs ukończony! Dalej: typy wartości a typy referencyjne — szczegółowo.

Często zadawane pytania

Czy lekcja „Zasady projektowania zorientowanego na protokoły” jest bezpłatna?

Tak — pełny tekst „Zasady projektowania zorientowanego na protokoły” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Swift Academy, przejdź na CoddyKit PRO. Kurs Swift Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Zasady projektowania zorientowanego na protokoły”?

Preferowanie kompozycji protokołów zamiast dziedziczenia klas w celu uzyskania elastycznego projektu. Ćwiczysz Swift Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Swift Academy?

Nie wymagamy żadnego doświadczenia. Swift Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Zasady projektowania zorientowanego na protokoły”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Swift Academy?

Tak. Każda lekcja Swift Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Kompozycja protokołów za pomocą &
Warunkowa zgodność z protokołem
Wymagania Self i projektowanie Equatable
Zasady projektowania zorientowanego na protokoły

← Powrót do Swift Academy