Ковариантность протоколов Swift для принципа Лисков и

Понимание проблемы ковариантности в Swift

Основная проблема, с которой вы сталкиваетесь, связана с текущим дизайном системы обобщений в Swift. Как упоминалось в обсуждении на Swift Forums, «в настоящее время обобщения являются инвариантными, тогда как аргументы функций и т. д. являются ковариантными» [forums.swift.org]. Это означает, что обобщённые типы в Swift не поддерживают ковариантность автоматически, что критично для правильной реализации принципа Лисковской подстановки (LSP).

При определении протокола с ассоциированными типами, например Path, Swift рассматривает эти типы как инвариантные ограничения. Поэтому, когда подтип, такой как SimplePath, реализует метод extend(), Swift не распознаёт, что SimplePath допустим в качестве возвращаемого типа там, где ожидается Path, даже если SimplePath соответствует Path.

// Это не работает из‑за инвариантности Swift
struct SimplePath: Path {
    func extend(move: Edge) -> SimplePath? {  // ✖ Невозможно преобразовать выражение возвращаемого значения типа 'SimplePath?' в тип 'Path?'
        // Реализация
    }
}

Проблема в том, что система типов Swift требует точного совпадения типов, а не распознаёт подтиповые отношения в обобщённых контекстах. Это ограничение касается не только ассоциированных типов, но и обобщённых параметров в целом.

Требования принципа Лисковской подстановки

Принцип Лисковской подстановки гласит, что «если S является подтипом T, то объекты типа T могут быть заменены объектами типа S» [holyswift.app]. Для вашего алгоритма обхода графа это означает, что любая реализация Path должна быть взаимозаменяемой с любой другой реализацией Path.

Для корректной работы LSP с протоколами необходимо соблюдение двух ключевых требований к вариации:

1. Ковариантность возвращаемых типов: подтипы должны иметь возможность возвращать более конкретные типы, чем требует протокол.
2. Контравариантность типов параметров: подтипы должны иметь возможность принимать более общие типы, чем требует протокол.

Как отмечено в документации Microsoft Press, «необходимо наличие ковариантности возвращаемых типов в подтипе» [microsoftpressstore.com]. Ваш метод extend() является идеальным примером, где нужна ковариантность — возвращаемый тип должен быть тем же самым, что и тип, реализующий протокол, а не только базовый протокол.

Ковариантность через обнуление типа (Type Erasure)

Одним из эффективных обходных путей реализации ковариантности с протоколами в Swift является использование обнуления типа. Эта техника включает создание обёртки, которая скрывает конкретный тип, но сохраняет соответствие протоколу.

Вот как можно реализовать обнуление типа для вашего протокола Path:

class AnyPath: Path {
    private let _distance: () -> Int
    private let _end: () -> Node
    private let _extend: (Edge) -> AnyPath?
    
    var distance: Int { return _distance() }
    var end: Node { return _end() }
    
    init<P: Path>(_ path: P) {
        _distance = { path.distance }
        _end = { path.end }
        _extend = { [weak self] edge in
            guard let newPath = path.extend(move: edge) else { return nil }
            return AnyPath(newPath)
        }
    }
    
    func extend(move: Edge) -> AnyPath? {
        return _extend(move)
    }
    
    init(start: Node) {
        // Требует реализации по умолчанию или фабричного паттерна
        fatalError("Используйте конкретные типы пути или реализуйте поведение по умолчанию")
    }
}

С помощью этого подхода ваш SimplePath теперь может возвращать AnyPath? из extend(), и система типов примет это:

struct SimplePath: Path {
    func extend(move: Edge) -> AnyPath? {
        let newPath = SimplePath(start: end) // упрощённый пример
        newPath.extendWith(move: move)
        return AnyPath(newPath)
    }
}

Проблема в том, что вы теряете проверку типов на этапе компиляции и некоторые преимущества производительности, но получаете возможность использовать разные реализации пути взаимозаменяемо.

Подход «протоколы как ограничения обобщений»

Более типобезопасный подход — использовать протоколы как ограничения обобщений, а не пытаться сделать сам протокол ковариантным. Этот метод использует существующую систему обобщений Swift, сохраняя при этом типобезопасность.

Вот как можно перестроить ваш алгоритм Search:

protocol Path {
    var distance: Int { get }
    var end: Node { get }
    init(start: Node)
    func extend(move: Edge) -> Self?
}

struct Search<P: Path> {
    func findPath(from start: Node, to target: Node) -> P? {
        var currentPath = P(start: start)
        // Реализация алгоритма поиска
        // Теперь можно использовать `currentPath.extend(move: edge)`, который возвращает P?
    }
}

Ключевая идея здесь — использовать Self в качестве возвращаемого типа. Когда тип соответствует протоколу, Swift автоматически понимает, что возвращаемый тип должен быть тем же самым, что и тип, реализующий протокол. Этот подход сохраняет типобезопасность и обеспечивает нужную ковариантность.

Однако у этого подхода есть ограничения. Как отмечено в обсуждении на Stack Overflow, «если вы используете typealias в протоколе, чтобы сделать его похожим на обобщённый, то вы не можете использовать его как тип переменной до тех пор, пока ассоциированный тип не будет разрешён» [stackoverflow.com]. Это означает, что вы не можете хранить типы, соответствующие Path, в коллекциях без знания их конкретного типа на этапе компиляции.

Решения на основе протокольно‑ориентированного дизайна

Более продвинутый подход включает использование техник протокольно‑ориентированного программирования для обхода ограничений ковариантности. Этот метод фокусируется на создании протоколов, которые описывают возможности, а не конкретные реализации.

Вот альтернативный дизайн, который разделяет представление пути от поведения обхода:

protocol PathRepresentable {
    associatedtype PathType: Path
    var path: PathType { get }
}

protocol Path {
    var distance: Int { get }
    var end: Node { get }
    init(start: Node)
    func extend(move: Edge) -> Self?
}

// Теперь ваш алгоритм поиска может работать с любым PathRepresentable
struct Search<PR: PathRepresentable> {
    func findPath(from start: Node, to target: Node) -> PR.PathType? {
        // Реализация, работающая с PR.PathType
    }
}

Этот подход позволяет сохранять типобезопасность при работе с разными реализациями пути. Ключ в разделении представления от поведения, что соответствует философии протокольно‑ориентированного дизайна Swift.

Как объясняет Khawer Khaliq в своей статье, «ключ к протокольно‑ориентированному мышлению — начать не с поиска абстракций для доменных сущностей, а с понимания того, что сущности будут делать и какие алгоритмы нам нужны» [khawerkhaliq.com].

Будущие изменения в языке Swift

Стоит отметить, что эволюция языка Swift может в конечном итоге решить эти ограничения ковариантности. В обсуждении на Swift Forums упоминается, что «если изменить способ реализации обобщений, то они могут стать ковариантными, и это добавит значительную полезность обобщениям Swift» [forums.swift.org].

Манипуляции, описанные в «Complete Generics Manifesto», включают такие функции, как «рекурсивные ограничения протоколов и произвольные требования в протоколах», которые в конечном итоге могут решить эти проблемы [stackoverflow.com]. Пока что разработчикам приходится работать с текущими ограничениями, используя описанные выше обходные пути.

Лучшие практики для обобщённых алгоритмов графов

На основе проведённого исследования, вот лучшие практики для реализации обобщённых алгоритмов обхода графов в Swift:

1. Используйте возвращаемые типы Self в методах протокола, когда нужна ковариантность:

   swift

   func extend(move: Edge) -> Self?
   

2. Используйте ограничения протоколов вместо попыток сделать протоколы ковариантными:

   swift

   struct Search<P: Path> { ... }
   

3. Рассмотрите обнуление типа, когда нужно хранить разные реализации в коллекциях:

   swift

   class AnyPath: Path { ... }
   

4. Разделяйте ответственность между представлением и поведением при работе с сложными протоколами:

   swift

   protocol PathRepresentable { ... }
   protocol Path { ... }
   

5. Используйте экзистенциальные типы с конкретными ограничениями, когда это уместно:

   swift

   func processPath(_ path: any Path) { ... }
   

Каждый подход имеет свои компромиссы, поэтому лучший выбор зависит от конкретного случая использования и требований к производительности. Для большинства алгоритмов обхода графов подход с возвращаемыми типами Self в сочетании с ограничениями протоколов обеспечивает наилучший баланс между типобезопасностью и гибкостью.

Источники

1. Swift Forums Discussion - Make generics covariant and add generics to protocols
2. Stack Overflow - Protocols and covariance - How to enable LSP in swift?
3. Stack Overflow - How to pass protocol with associated type (generic protocol) as parameter in Swift?
4. Hacking with Swift - Understanding protocol associated types and their constraints
5. Khawer Khaliq Blog - A Protocol-Oriented Approach to Associated Types and Self Requirements in Swift
6. Hacking with Swift - How to fix the error “protocol can only be used as a generic constraint because it has Self or associated type requirements”
7. Holy Swift - The Liskov Substitution Principle and Swift
8. Microsoft Press Store - The Liskov Substitution Principle

Заключение

Реализация ковариантности с протоколами в Swift для поддержки принципа Лисковской подстановки требует обхода текущих ограничений системы обобщений языка. Ключевые решения включают:

1. Использовать возвращаемые типы Self в методах протокола для обеспечения ковариантности подтипов.
2. Реализовать обнуление типа с помощью обёрток, когда необходимо хранить разные реализации в коллекциях.
3. Использовать ограничения протоколов в обобщённых типах вместо попыток сделать протоколы самими по себе ковариантными.
4. Разделять представление и поведение в сложных протоколах для сохранения типобезопасности.
5. Следить за будущими улучшениями языка, которые могут добавить нативную поддержку ковариантности.

Для вашего алгоритма обхода графа наиболее практичным подходом, скорее всего, будет использование возвращаемых типов Self в сочетании с ограничениями протоколов, поскольку это сохраняет типобезопасность и обеспечивает нужную ковариантность для LSP. Хотя Swift в настоящее время не поддерживает полную ковариантность с протоколами, эти обходные пути предоставляют эффективные решения для большинства реальных случаев.