POP pitfalls: где начинаются сюрпризы с dispatch

1. Откуда берутся «сюрпризы» в POP и что такое dispatch

Слово dispatch звучит так, будто сейчас мы будем вызывать спецназ компилятора (и где-то рядом уже нервно курит DispatchQueue). На деле всё проще: dispatch — это правило, по которому Swift выбирает, какую именно реализацию метода выполнить. И «сюрприз» начинается тогда, когда мы ожидаем поведение как в наследовании (переопределение), но пишем код в стиле протоколов и extension, где часть вызовов выбирается иначе.

Когда вы пишете POP‑код, у вас обычно есть три «места», где может жить метод:

1. как требование в протоколе;
2. как default‑реализация требования в extension протокола;
3. как метод, который существует только в extension, но не объявлен в протоколе.

И вот третий вариант — главный герой серии «почему мой код делает не то, что я думаю».

2. Конкретный тип vs any Protocol

Самая частая ситуация в реальном коде выглядит так: у вас есть конкретный тип Book, у него есть метод, всё отлично. Потом вы решаете «обобщить» и хранить разные сущности в массиве any Something, чтобы обрабатывать их одинаково. И внезапно метод начинает вести себя иначе — или вообще «исчезает». Это не баг компилятора, это следствие того, что именно вы положили в протокол: требования или просто «удобняшки» в extension.

Важно помнить: any Protocol — это existential (тип‑контейнер), который «стирает» конкретный тип и оставляет снаружи только контракт. В Swift это намеренно подчёркнуто ключевым словом any, чтобы вы не забывали: абстракция имеет цену — в том числе в виде ограничений и особенностей поведения.

Сейчас посмотрим на самый классический POP‑pitfall: два метода с одинаковым именем, один в типе, другой в extension, и разные результаты вызова.

3. Pitfall №1: метод есть в extension, но не в протоколе

Представим минимальный пример. Мы делаем протокол «умеет прощаться». В протоколе ничего не требуем (он пустой), а в extension добавляем метод bye() — вроде бы удобно: «любой Farewell умеет bye». Потом в конкретном типе тоже пишем bye(), ожидая, что оно «переопределит» extension‑версию.

Пример: «переопределение», которого не существует

import Foundation

protocol Farewell { }

extension Farewell {
    func bye() -> String { "Bye from extension" }
}

struct Person: Farewell {
    func bye() -> String { "Bye from Person" }
}

let concrete = Person()
let asProtocol: any Farewell = concrete

print(concrete.bye())      // Bye from Person
print(asProtocol.bye())    // Bye from extension

Если вы сейчас сказали «эээ… что?» — вы увидели главный POP‑сюрприз.

Почему так? Потому что bye() не является требованием протокола. Это просто метод, добавленный в extension. Такие методы не участвуют в полиморфном выборе реализации при вызове через any P (то есть не ведут себя как «виртуальные» методы из ООП‑мира).

Проще говоря: при вызове через any Farewell компилятор «видит» только то, что гарантирует протокол. А протокол Farewell гарантирует… ничего. Поэтому bye() берётся из extension как «известная функция», и реализация Person.bye() не рассматривается как «переопределение».

4. Как исправить: метод должен быть требованием

Чтобы вызов был полиморфным через any Protocol, метод обязан быть требованием протокола. Тогда Swift строит механизм, который позволяет найти «правильную» реализацию для конкретного типа (концептуально это можно представлять как «таблицу соответствий» требований протокола конкретным функциям типа).

Пример: делаем bye() требованием

import Foundation

protocol Farewell {
    func bye() -> String
}

extension Farewell {
    func bye() -> String { "Bye from extension" }  // default для тех, кто не реализовал
}

struct Person: Farewell {
    func bye() -> String { "Bye from Person" }
}

let concrete = Person()
let asProtocol: any Farewell = concrete

print(concrete.bye())      // Bye from Person
print(asProtocol.bye())    // Bye from Person

Теперь всё «как ожидается»: метод — требование, значит при вызове через any Farewell выбирается реализация конкретного типа (или default, если тип свою не дал).

Важная мысль: default‑реализация — это не «extension‑метод сам по себе». Default‑реализация работает только тогда, когда метод объявлен в протоколе как требование.

5. Как Swift выбирает реализацию

Сейчас чуть структурируем, но без ухода в «компиляторные джунгли». Воспринимайте это как карту, а не как экзамен по внутренностям Swift.

Когда вы пишете:

• value.method() на конкретном типе — компилятор обычно знает, какой метод вызвать.
• p.method() где p: any P — компилятор обязан соблюдать правила «протокол как контракт».

Условно можно нарисовать так:

flowchart TD
    A["Вызов на конкретном типе Person().bye()"] --> B["Компилятор видит Person"]
    B --> C["Берём Person.bye()"]

    D["Вызов через any Protocol (asProtocol).bye()"] --> E["Компилятор видит только контракт Farewell"]
    E --> F{"bye() — требование?"}
    F -->|да| G["Выбираем реализацию через механизм протокола (концептуально: witness table)"]
    F -->|нет| H["Берём реализацию из extension Farewell"]

И это ровно то, что мы наблюдали: если метод не требование, any P не обязан «уважать» одноимённый метод конкретного типа.

6. Другие ловушки: helper‑методы и Self

Helper‑методы в extension могут «стрелять», если конфликтуют именами

Когда вы добавляете helper‑метод в extension, часто хочется назвать его «как логично»: print(), describe(), format(), render(). И иногда такой helper случайно совпадает по имени с методом в конкретном типе. После этого вы получаете ситуацию как в примере с bye().

Тут важно не столько «никогда так не делайте» (иногда это нормально), сколько помнить правило: совпадение имён — не переопределение. В Swift переопределение — это про классы и override, а протокольные extension живут по другим правилам.

Чтобы не превращать код в детектив «почему вызвался не тот метод», хороший стиль такой: helper‑методы называют так, чтобы было ясно, что это именно helper, а не «контракт». Например, не render(), а renderLine() или renderDebugLine(). А ключевое поведение — фиксируют в требованиях протокола.

Self в методах: почему часть API недоступна на any Protocol

Есть отдельная категория «сюрпризов», когда вы вроде бы добавили метод в extension, но при попытке вызвать его через any P компилятор говорит: «нельзя». Это часто связано с тем, что метод использует Self в параметрах (то есть принимает значение того же конкретного типа, что и receiver). Тогда для existential (any P) это может быть небезопасно: внутри коробки может лежать один тип, а вы попытаетесь передать другой.

Ниже — простой «учебный» вариант без углубления в generics.

Пример: метод с Self и почему any может запретить вызов

Пример (пример компилируется, потому что мы не делаем запрещённый вызов — запрет показан как комментарий):

import Foundation

protocol Taggable { }

extension Taggable {
    func merge(with other: Self) -> String {
        "Merged"
    }
}

struct Book: Taggable { }
struct Movie: Taggable { }

let b: any Taggable = Book()

// b.merge(with: Book()) // так писать нельзя: Self неизвестен для any Taggable

Идея такая: any Taggable — коробка «какой-то Taggable». Но метод merge(with:) требует точно такой же тип, что лежит внутри коробки. А снаружи мы этого не знаем.

7. Практика: Renderable в LibraryCLI

Представим, что у нас есть простая CLI‑программа «библиотека»: мы храним книги и печатаем результаты пользователю. На уровне «концепции приложения» удобно сделать протокол, который умеет «рисовать строку» для вывода.

И вот здесь POP‑pitfall может ударить очень жизненно: вы хотите хранить разные сущности в массиве any Renderable, а форматирование каждой сущности — своё. Если вы оформите это как «метод только в extension», вы рискуете получить одинаковый вывод для всех.

Неправильный дизайн: метод только в extension

import Foundation

protocol Renderable { }

extension Renderable {
    func render() -> String { "[unknown]" }
}

struct Book: Renderable {
    let title: String
    func render() -> String { "Book: \(title)" }
}

let items: [any Renderable] = [Book(title: "Swift 6.2")]

print(items[0].render())   // [unknown]

С точки зрения новичка это выглядит как «ну почему?!». С точки зрения правил — всё честно: render() не требование, значит при вызове через any Renderable берётся версия extension.

Правильный дизайн: делаем render() требованием

import Foundation

protocol Renderable {
    func render() -> String
}

extension Renderable {
    func render() -> String { "[unknown]" } // default-логика, если нужна
}

struct Book: Renderable {
    let title: String
    func render() -> String { "Book: \(title)" }
}

let items: [any Renderable] = [Book(title: "Swift 6.2")]

print(items[0].render())   // Book: Swift 6.2

Теперь LibraryCLI может безопасно хранить элементы как any Renderable и печатать их одинаковым способом, но с разными реализациями.

8. Правило «требование vs helper»

В реальном проекте вы почти всегда будете смешивать два подхода:

Методы‑требования нужны, когда вы хотите полиморфизм: разные типы делают по‑разному, и это должно работать через any Protocol.

Helper‑методы в extension хороши, когда это «обёртка» над требованиями. То есть helper не пытается быть «переопределяемым», а просто строит удобство вокруг того, что уже является контрактом.

Это ключ к предсказуемости: helper должен опираться на требования, а не конкурировать с ними.

Пример: «безопасный helper» — extension вызывает требование

import Foundation

protocol Renderer {
    func render() -> String
}

extension Renderer {
    func renderLine() -> String {
        "• " + render()
    }
}

struct Book: Renderer {
    let title: String
    func render() -> String { "Book: \(title)" }
}

let r: any Renderer = Book(title: "Algorithms")
print(r.renderLine())      // • Book: Algorithms

Здесь renderLine() хоть и не требование, но он внутри вызывает render() — требование. Поэтому итоговое поведение остаётся завязано на конкретный тип, и сюрпризов обычно меньше.

9. Памятка: где начинается «не то поведение»

Иногда полезно один раз увидеть это в таблице и потом не наступать на грабли каждый вторник.

Строчка про Self — это как табличка «осторожно, мокрый пол»: не обязательно падать, но шанс заметный.

10. Типичные ошибки и почему они происходят

Ошибка №1: ожидать, что метод из extension «переопределяется» в типе.
Обычно это рождается из привычки к ООП: «если я написал метод с тем же именем в типе, значит он заменит дефолт». В протокольных extensions это не так: совпадение имени не делает метод «виртуальным». Если метод не объявлен требованием, вызов через any Protocol вполне может выбрать реализацию из extension, что выглядит как подмена.

Ошибка №2: прятать ключевое поведение в helper‑методе extension, а потом хранить значения как any Protocol.
Пока вы вызываете методы на конкретных типах, всё кажется нормальным. Но стоит вам передать значение как any P, и ваш «важный» метод может либо стать недоступным, либо начать работать «по версии extension». Если метод действительно важен для внешнего кода — он должен быть требованием протокола, иначе контракт получается «на словах».

Ошибка №3: делать протокол пустым и пытаться «нарастить всё мясо» в extension, а затем удивляться отсутствию полиморфизма.
Пустой протокол — это нормально как «маркер», но если вы ждёте от него полиморфного поведения, ему нужны требования. Иначе any P — это коробка без обещаний. Снаружи нельзя ожидать, что разные типы будут вести себя по‑разному, если вы это не зафиксировали контрактом.

Ошибка №4: писать методы с параметром Self и затем пытаться вызывать их на any Protocol.
На конкретных типах такие методы выглядят естественно: «объедини два значения одного типа». Но для existential это опасно: снаружи мы не знаем, какой конкретный тип внутри коробки, и Swift часто запретит такой вызов. В результате вы получаете ошибку компиляции member cannot be used on value of protocol type.... Это не придирка, а защита типов от некорректных вызовов.

Ошибка №5: давать helper‑методам слишком общие имена и случайно конфликтовать с методами конкретных типов.
Когда extension добавляет describe() или print() (в смысле «верни строку») и тип тоже имеет describe(), вы создаёте мину замедленного действия: на конкретном типе вызов может идти в одно место, на any P — в другое. Выход обычно простой: либо сделать метод требованием, либо переименовать helper так, чтобы он явно был helper (например, renderLine() вместо render()), либо вынести общую логику в helper, который вызывает требование.