swift-protocol-oriented-programming

name	Swift Protocol-Oriented Programming
user-invocable	false
description	Use when protocol-oriented programming in Swift including protocol extensions, default implementations, protocol composition, associated types, and designing flexible, reusable abstractions that favor composition over inheritance.
allowed-tools	[]

Swift Protocol-Oriented Programming

Introduction

Protocol-oriented programming (POP) is Swift's paradigm for building flexible, composable abstractions without the rigid hierarchies of class inheritance. Protocols define interfaces that types can adopt, while protocol extensions provide default implementations and capabilities to multiple types simultaneously.

This approach offers the flexibility of composition, the performance of static dispatch, and the ability to extend value types like structs and enums. POP is foundational to Swift's standard library and enables powerful patterns for code reuse, testing, and API design.

This skill covers protocol design, extensions, associated types, composition, and practical patterns for building protocol-oriented architectures.

Protocol Basics and Design

Protocols define contracts that types must fulfill, specifying required properties, methods, and initializers without providing implementations.

// Basic protocol definition
protocol Drawable {
    var lineWidth: Double { get set }
    var color: String { get }

    func draw()
    mutating func resize(by factor: Double)
}

// Protocol adoption in struct
struct Circle: Drawable {
    var lineWidth: Double
    let color: String
    var radius: Double

    func draw() {
        print("Drawing circle with radius \(radius)")
    }

    mutating func resize(by factor: Double) {
        radius *= factor
    }
}

// Protocol adoption in class
class Rectangle: Drawable {
    var lineWidth: Double
    let color: String
    var width: Double
    var height: Double

    init(lineWidth: Double, color: String, width: Double, height: Double) {
        self.lineWidth = lineWidth
        self.color = color
        self.width = width
        self.height = height
    }

    func draw() {
        print("Drawing rectangle \(width)x\(height)")
    }

    func resize(by factor: Double) {
        width *= factor
        height *= factor
    }
}

// Using protocols as types
func render(shape: Drawable) {
    print("Rendering with \(shape.color) color")
    shape.draw()
}

let circle = Circle(lineWidth: 2.0, color: "red", radius: 5.0)
render(shape: circle)

// Protocol requirements for initializers
protocol Identifiable {
    var id: String { get }
    init(id: String)
}

struct User: Identifiable {
    let id: String
    let name: String

    init(id: String) {
        self.id = id
        self.name = "Unknown"
    }
}

Well-designed protocols are focused and cohesive, defining a single responsibility rather than mixing unrelated requirements.

Protocol Extensions

Protocol extensions provide default implementations to all adopting types, enabling code reuse without inheritance and retroactive modeling of existing types.

// Protocol with extension providing defaults
protocol Greetable {
    var name: String { get }
    func greet() -> String
    func formalGreet() -> String
}

extension Greetable {
    func greet() -> String {
        return "Hello, \(name)!"
    }

    func formalGreet() -> String {
        return "Good day, \(name)."
    }
}

// Type adopts protocol, gets defaults
struct Person: Greetable {
    let name: String
    // greet() and formalGreet() provided by extension
}

// Type can override defaults
struct Robot: Greetable {
    let name: String

    func greet() -> String {
        return "GREETINGS, \(name.uppercased())"
    }
}

// Conditional extensions
extension Collection where Element:  {
     () ->  {
          first  first  {   }
         allSatisfy {   first }
    }
}

 numbers  [, , , ]
(numbers.allEqual()) 


   :  {
     () {
        
        draw()
    }
}


  {
     description:  {
         
    }
}


  {
     () -> [: ]
}

  {
     () ->  {
         dict  toJSON()
          data   .data(
            withJSONObject: dict
        ),
               string  (data: data, encoding: .utf8)  {
             
        }
         string
    }
}

Protocol extensions enable retroactive modeling—adding protocol conformance to types you don't own, including standard library types.

Associated Types

Associated types create generic protocols, allowing conforming types to specify concrete types that satisfy protocol requirements.

// Protocol with associated type
protocol Container {
    associatedtype Item

    var count: Int { get }
    mutating func append(_ item: Item)
    subscript(i: Int) -> Item { get }
}

// Concrete type specifies Item
struct IntStack: Container {
    typealias Item = Int // explicit, but can be inferred

    private var items: [Int] = []

    var count: Int {
        return items.count
    }

    mutating func append(_ item: Int) {
        items.append(item)
    }

    subscript(i: Int) -> Int {
        return items[i]
    }
}

// Generic type with associated type
struct Stack<Element>: Container {
    private var items: []  []

     count:  {
         items.count
    }

      ( : ) {
        items.append(item)
    }

    (: ) ->  {
         items[i]
    }
}


 <: >( : )  .   {
     i  container.count {
        (container[i])
    }
}


  {
     : 
     

     ( : ) -> []
     ( : ) -> []
}


  {
     
     

     ( : ) -> 
}

 :  {
     ( : ) ->  {
         (input)  
    }
}


  {
       

     ( : ) -> 
}

 :  {
     ( : ) ->  {
           other
    }
}

Associated types enable protocol-based generic programming, providing flexibility while maintaining type safety and performance.

Protocol Composition

Protocol composition combines multiple protocols into a single requirement, enabling precise type constraints without creating protocol hierarchies.

// Individual protocols
protocol Named {
    var name: String { get }
}

protocol Aged {
    var age: Int { get }
}

protocol Addressable {
    var address: String { get }
}

// Function requiring multiple protocols
func displayInfo(for entity: Named & Aged) {
    print("\(entity.name) is \(entity.age) years old")
}

struct Employee: Named, Aged, Addressable {
    let name: String
    let age: Int
    let address: String
}

let employee = Employee(name: "Alice", age: 30, address: "123 Main St")
displayInfo(for: employee)

// Composition with classes
protocol Purchasable {
    var price: Double { get }
}

func processPurchase(:  & ) {
    
    ()
}


  {
     items: [ & ]  []

     ( :  & ) {
        items.append(item)
    }
}


 :  {
     ( : ) -> 
}

 <: >(: []) -> [] {
     items.sorted { .isLessThan() }
}


    &  & 

 (: ) {
    ()
}


 <>( : ,  : ) -> []  :  &  {
     [a, b].sorted { .age  .age }
}

Protocol composition creates precise constraints without the fragility of deep inheritance hierarchies or the overhead of creating new protocols.

Protocol Witnesses and Type Erasure

Type erasure hides concrete types behind protocol interfaces, enabling heterogeneous collections and abstracting implementation details.

// Problem: protocols with associated types can't be used as types
protocol Producer {
    associatedtype Item
    func produce() -> Item
}

// Type-erased wrapper
struct AnyProducer<T>: Producer {
    typealias Item = T

    private let _produce: () -> T

    init<P: Producer>(_ producer: P) where P.Item == T {
        _produce = producer.produce
    }

    func produce() -> T {
        return _produce()
    }
}

// Concrete producers
struct IntProducer: Producer {
    func produce() -> Int {
        return 42
    }
}

struct StringProducer: Producer {
    func produce() -> String {
        return 
    }
}


 producers: []  [
    (()),
    (())
]


 () -> <> {
     array  [, , , , ]
     (array)
}


  {
     
     () -> 
}

 <>:  {
       

      _fetch: () -> 

    <: >( : )  .   {
        _fetch  source.fetch
    }

     () ->  {
         _fetch()
    }
}


  {
     () -> 
}

 :  {
     () ->  {  }
}

 :  {
     () ->  {  }
}

 animals: [ ]  [(), ()]

Type erasure trades some type information for flexibility, enabling protocol abstractions to work as concrete types in collections and properties.

Protocol-Oriented Architecture Patterns

Protocol-oriented design supports testability, modularity, and clean architecture through dependency injection and protocol-based abstractions.

// Dependency injection with protocols
protocol NetworkService {
    func fetch(url: URL) async throws -> Data
}

protocol DataStore {
    func save(_ data: Data, key: String) throws
    func load(key: String) throws -> Data
}

// Concrete implementations
struct URLSessionNetworkService: NetworkService {
    func fetch(url: URL) async throws -> Data {
        let (data, _) = try await URLSession.shared.data(from: url)
        return data
    }
}

struct UserDefaultsDataStore: DataStore {
    func save(_ data: Data, key: String)  {
        .standard.set(data, forKey: key)
    }

     (: )  ->  {
          data  .standard.data(forKey: key)  {
             .notFound
        }
         data
    }
}

 :  {
     notFound
}


  {
      network: 
      store: 

    (: , : ) {
        .network  network
        .store  store
    }

     (: , : )   {
         data    network.fetch(url: url)
         store.save(data, key: key)
    }
}


 :  {
     mockData: 

     (: )   ->  {
         mockData
    }
}

 :  {
     storage: [: ]  [:]

      ( : , : )  {
        storage[key]  data
    }

     (: )  ->  {
          data  storage[key]  {
             .notFound
        }
         data
    }
}


  {
     <: >( : []) -> []
}

 :  {
     <: >( : []) -> [] {
         array.count    {  array }
        
         array.sorted()
    }
}

 :  {
     <: >( : []) -> [] {
        
         array.sorted()
    }
}

  {
     strategy: 

    (: ) {
        .strategy  strategy
    }

     <: >( : []) -> [] {
         strategy.sort(array)
    }
}

Protocol-oriented architecture improves testability by allowing mock implementations and supports flexibility by enabling runtime strategy changes.

Best Practices

1. Design small, focused protocols with single responsibilities rather than large protocols mixing unrelated requirements

2. Provide default implementations in extensions to reduce boilerplate and allow selective customization by conforming types

3. Prefer protocol composition over inheritance to create precise constraints without fragile hierarchies

4. Use associated types for generic protocols when conforming types need to specify concrete types for requirements

5. Apply protocol extensions conditionally with where clauses to provide specialized behavior for constrained types

6. Leverage value types with protocols to gain composition benefits without reference semantics or inheritance limitations

7. Create type-erased wrappers for protocols with associated types when heterogeneous collections or abstraction is needed

8. Design for testability by depending on protocol abstractions rather than concrete types in business logic

9. Use protocol witnesses for dependency injection to decouple components and enable flexible configuration

10. Document protocol semantics clearly, including performance expectations and usage constraints beyond type signatures

Common Pitfalls

1. Creating overly broad protocols that mix unrelated concerns leads to forced implementations and violation of interface segregation

2. Forgetting mutating keyword on protocol methods that modify value types causes compilation errors in struct implementations

3. Protocol extension shadowing where methods in extensions don't override implementations, using static dispatch instead

4. Not constraining associated types sufficiently allows conforming types to choose inappropriate concrete types

5. Overusing type erasure when simpler solutions exist adds complexity and obscures actual types unnecessarily

6. Ignoring protocol vs class dispatch differences leads to unexpected behavior when protocols use extensions and classes use inheritance

7. Creating protocol hierarchies that mimic classes defeats the purpose of protocol-oriented programming's compositional benefits

8. Not providing default implementations when most conforming types would use the same logic wastes opportunities for reuse

9. Using protocols for everything when concrete types suffice adds abstraction overhead without meaningful benefit

10. Failing to test protocol conformance thoroughly allows bugs in implementations that satisfy signatures but violate semantics

When to Use This Skill

Use protocol-oriented programming when building Swift applications that require flexibility, testability, and code reuse across value types and classes. This applies to iOS, macOS, watchOS, tvOS, and server-side Swift development.

Apply protocols and extensions when designing frameworks, libraries, or modules that need to support multiple implementations or allow clients to customize behavior without subclassing.

Employ protocol composition when creating precise type constraints for functions and properties, especially in generic code that needs to operate on types satisfying multiple requirements.

Leverage associated types when building generic abstractions like collections, transformers, or data sources where conforming types need to specify concrete types.

Use protocol-based dependency injection in architectural patterns like MVVM, VIPER, or Clean Architecture to improve testability and decouple components.

Resources

• Protocol-Oriented Programming WWDC Session
• Swift Language Guide - Protocols
• Protocol Extensions Documentation
• Advanced Swift by Chris Eidhof
• Swift Evolution Proposals