Protocol-Oriented Programming and Generics

Introduction

Swift supports several complementary ways to model software: structures and enumerations, classes and inheritance, protocols, protocol extensions, and generics. Protocol-oriented programming (POP) emphasizes defining capabilities and composing small abstractions rather than building every design around class hierarchies. Generics provide reusable algorithms and data structures while preserving compile-time type safety.

These ideas are especially important in iOS development. A view controller may delegate work to another object, a data source may expose an associated type, and a reusable networking component may operate on any type conforming to a decoding protocol. Understanding the boundaries between protocols, generics, and inheritance enables developers to design code that is flexible without becoming vague or difficult to maintain.

Learning Objectives

By the end of this chapter, you should be able to:

• define and adopt Swift protocols;
• use protocol extensions to provide shared behavior;
• apply delegation to separate responsibilities;
• explain associated types and protocol requirements involving them;
• write generic functions, types, and constraints;
• distinguish existential values such as any Protocol from opaque values such as some Protocol;
• compose protocols and apply protocol-oriented design;
• compare protocol composition with class inheritance;
• evaluate the strengths and limitations of each approach in an iOS application.

1. Protocols as Contracts

A protocol defines requirements that a conforming type must satisfy. It can require properties, methods, initializers, subscripts, and associated types. A protocol does not normally store instance data. It describes what a type can do, not what it is in an inheritance hierarchy.

protocol IdentifiableItem {
    var identifier: String { get }
    func displayName() -> String
}

struct Product: IdentifiableItem {
    let identifier: String
    let name: String

    func displayName() -> String {
        name
    }
}

Product is a value type, yet it conforms to IdentifiableItem. A class, enumeration, or actor could conform as well. This separation between capability and concrete representation is a major reason protocols are useful.

A requirement such as var identifier: String { get } means that the property must be readable. A conforming type may implement it as a stored property or a computed property. If the protocol declares { get set }, the conforming property must be both readable and writable.

Protocols can inherit from other protocols:

protocol Persistable {
    func save()
}

protocol Synchronizable: Persistable {
    func synchronize()
}

Protocol inheritance combines contracts; it does not create stored state or class-style implementation inheritance.

2. Protocol Extensions and Default Behavior

A protocol extension can provide shared implementations, computed properties, or additional methods.

protocol Describable {
    var title: String { get }
}

extension Describable {
    var summary: String {
        "Item: \(title)"
    }
}

struct Article: Describable {
    let title: String
}

Article receives summary automatically. This reduces duplication while allowing each conforming type to override the default by supplying its own implementation.

Extensions can also be conditionally available:

extension Collection where Element: Equatable {
    func containsDuplicates() -> Bool {
        for item in self {
            if firstIndex(of: item) != lastIndex(of: item) {
                return true
            }
        }
        return false
    }
}

The constraint means that this method is available only when the collection’s elements support equality. Protocol extensions therefore combine reuse with precise type requirements.

A subtle issue concerns static dispatch. If a method exists only in a protocol extension and is not declared as a protocol requirement, calls made through a protocol-typed value use the extension implementation rather than a same-named method introduced by the conforming type. To obtain dynamically selected behavior through the protocol interface, declare the method in the protocol itself.

protocol Reportable {
    func report()
}

extension Reportable {
    func report() { print("Default report") }
}

Here report is a requirement, so a conforming type can provide a specialized implementation that is used through the protocol interface.

3. Delegation in iOS Development

Delegation is a design pattern in which one object assigns a responsibility to another object through a protocol. The delegating object communicates events or requests; the delegate supplies behavior.

protocol DownloadDelegate: AnyObject {
    func downloadDidFinish(data: Data)
    func downloadDidFail(error: Error)
}

final class Downloader {
    weak var delegate: DownloadDelegate?

    func complete(with data: Data) {
        delegate?.downloadDidFinish(data: data)
    }
}

AnyObject restricts adoption to class instances. This is appropriate when the delegate property is weak, because weak references apply to class-bound references. Weak delegation is important for avoiding retain cycles: the downloader should not keep the view controller alive after the view controller no longer needs it.

Delegation is valuable when one object should report events without knowing the concrete type of its collaborator. UIKit uses this pattern extensively through types such as table-view data sources and delegates.

A good delegate protocol should be narrow, cohesive, and named according to the responsibility it represents. Optional behavior can be modeled with optional protocol requirements in Objective-C-compatible protocols, but in modern Swift it is often clearer to provide default implementations or use separate protocols.

4. Protocol Composition

A value can be required to conform to several protocols at once. Swift expresses this with &:

func archive(_ item: any Codable & Identifiable) {
    // item satisfies both contracts
}

A protocol composition does not create a new protocol declaration. It describes a temporary combined constraint. Class requirements may also appear in a composition, for example UIViewController & SomeProtocol.

Composition supports capability-based design. Instead of requiring an object to belong to a particular superclass, a function can require exactly the capabilities it needs. This generally reduces coupling and improves testability.

5. Associated Types

An associated type is a placeholder for a type used by a protocol. It allows a protocol to describe relationships between types without fixing one concrete type in the protocol declaration.

protocol Repository {
    associatedtype Item
    func fetch() async throws -> [Item]
    func save(_ item: Item) async throws
}

struct UserRepository: Repository {
    typealias Item = User

    func fetch() async throws -> [User] { [] }
    func save(_ item: User) async throws { }
}

For UserRepository, the associated type Item is User. Another repository can use Product or another model. The compiler checks that the input and output types agree.

Protocols with associated types are excellent generic constraints, but they cannot always be used directly as ordinary existential types when code must refer to the unknown associated type. A generic function preserves the relationship:

func refresh<R: Repository>(_ repository: R) async throws -> [R.Item] {
    try await repository.fetch()
}

The compiler knows that the returned elements are the repository’s own Item type.

6. Generics

Generics allow one implementation to work with many types while retaining static type checking. A generic function introduces a type parameter in angle brackets.

func firstElement<T>(of values: [T]) -> T? {
    values.first
}

T is not a concrete type. At each call site, Swift infers or receives a specific type, such as Int or String.

Generic types are used throughout the standard library:

struct Stack<Element> {
    private var items: [Element] = []

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

    mutating func pop() -> Element? {
        items.popLast()
    }
}

The same Stack can store integers, strings, or custom values. The implementation does not need unsafe casts.

Generic Constraints

A generic parameter can be constrained to a protocol:

func areEqual<T: Equatable>(_ a: T, _ b: T) -> Bool {
    a == b
}

Multiple constraints can be written using a composition:

func printID<T: Identifiable & CustomStringConvertible>(_ value: T) {
    print(value.id, value.description)
}

A where clause expresses more detailed relationships:

func copyMatching<S, D>(from source: S, to destination: inout D)
where S: Sequence, D: RangeReplaceableCollection,
      S.Element == D.Element {
    destination.append(contentsOf: source)
}

The equality constraint S.Element == D.Element ensures that elements produced by the source can be inserted into the destination. Constraints are not merely documentation; they allow the compiler to reject invalid calls and expose operations known to be safe.

Generics and Performance

Generics are generally specialized by the compiler for concrete types, which can provide performance comparable to specialized code. Existential values such as any Protocol introduce type erasure and may have different performance and allocation characteristics. Performance should be measured rather than assumed, especially in UI rendering or large data-processing paths.

7. some and any

Swift distinguishes opaque types and existential types.

An opaque return type uses some Protocol:

func makeView() -> some View {
    Text("Welcome")
}

The caller knows that the result conforms to View, but the concrete type is hidden. The implementation chooses one specific underlying type for that function invocation. All return paths must produce the same underlying type, usually achieved with a builder or a wrapper.

An existential uses any Protocol:

func log(_ value: any CustomStringConvertible) {
    print(value.description)
}

The variable can contain values of different conforming concrete types at different times. The concrete type is dynamically carried with the value. Existentials are useful for heterogeneous collections and runtime substitution, whereas generics and opaque types preserve more static type information.

8. Protocol-Oriented Design Compared with Inheritance

Inheritance creates an “is-a” relationship between classes. A subclass receives superclass behavior and can override methods. It is appropriate when there is a genuine, stable hierarchy and shared identity or lifecycle behavior.

Protocol-oriented design models capabilities such as Cacheable, Validatable, or Syncing. A type can adopt multiple protocols, including value types such as structures and enumerations. Shared behavior is commonly supplied through protocol extensions rather than a single superclass.

POP is not a rule that inheritance must never be used. A view controller remains a useful subclass of UIViewController, and a specialized class may legitimately inherit state and lifecycle behavior. The design question is whether reuse depends on a true subtype relationship or merely on shared capabilities.

9. Worked Example: A Generic, Protocol-Based Cache

The following cache separates the cache contract from its storage implementation:

protocol Cache {
    associatedtype Key: Hashable
    associatedtype Value

    func value(for key: Key) -> Value?
    mutating func insert(_ value: Value, for key: Key)
}

struct MemoryCache<K: Hashable, V>: Cache {
    private var storage: [K: V] = [:]

    func value(for key: K) -> V? {
        storage[key]
    }

    mutating func insert(_ value: V, for key: K) {
        storage[key] = value
    }
}

The dictionary constraint requires K to conform to Hashable. The cache can therefore store any hashable key and any value without casts. A production iOS application could add expiration, memory warnings, persistence, or actor isolation, but those concerns need not be part of the basic contract.

A generic consumer can work with any cache:

func load<C: Cache>(_ key: C.Key, from cache: C) -> C.Value? {
    cache.value(for: key)
}

This design is easy to test because a lightweight fake cache can conform to Cache. It also avoids forcing all cache implementations into a shared superclass.

10. Case Study: Image Loading in an iOS Application

Background

Consider an illustrative iOS news application that displays many remote article images. The first version places URL-session logic, memory caching, error handling, and image-view updates directly in a view controller.

Problem

The view controller becomes difficult to test and reuse. A change from memory caching to disk caching affects UI code. Network responses may arrive after a cell has been reused, causing an image to appear in the wrong row.

Analysis

The application needs several distinct capabilities: image retrieval, caching, cancellation, and presentation. These are responsibilities rather than reasons for a single inheritance hierarchy.

Approach

Define narrow protocols:

protocol ImageFetching {
    func fetch(_ url: URL) async throws -> Data
}

protocol ImageCaching {
    associatedtype Key: Hashable
    associatedtype Value
    func value(for key: Key) -> Value?
    mutating func insert(_ value: Value, for key: Key)
}

A generic image-loading service can receive an image fetcher and a cache. A memory cache and a disk cache can implement the same conceptual capability without sharing a superclass. The view controller or collection-view cell becomes a consumer of the service rather than its owner of every detail. When a cell is reused, the task can be cancelled and the result can be checked against the cell’s current URL before presentation.

Outcome

The architecture improves substitution and testing. A test can inject a fake fetcher that returns known data, while a preview can inject a deterministic cache. The UI layer remains responsible for presentation, not transport or persistence.

Learning Points

• Protocols express boundaries between responsibilities.
• Generics preserve relationships between keys, values, and implementations.
• Delegation or injected protocols reduce direct dependencies.
• Cancellation and cell identity remain application concerns; POP does not automatically solve lifecycle errors.

11. Limitations and Best Practices

Protocol-oriented code can become over-engineered when every class receives a protocol with no realistic alternative implementation. Use abstractions where substitution, testing, or independent evolution is valuable.

Protocols should be cohesive. A protocol that combines networking, caching, analytics, and presentation violates the principle of focused responsibilities. Prefer several small protocols when clients need different capabilities.

Choose value types for independent data and behavior without identity. Choose classes or actors when identity, shared mutable state, reference semantics, or lifecycle management is central. Protect shared mutable state with appropriate concurrency tools; a protocol alone does not make an implementation thread-safe.

Use access control deliberately. Public protocols are API commitments: changing requirements can break adopters. Default implementations can preserve convenience, but they should not conceal important behavior or create surprising dispatch rules.

When using any, recognize that type erasure may remove relationships the compiler could otherwise verify. Prefer generics when a function needs to preserve the relationship between input and output types. Prefer some when an implementation should remain hidden while one concrete type is returned.

12. Contemporary Swift Practice

Modern Swift uses explicit any for existential protocol types in contexts where the language mode requires it. Swift concurrency also encourages protocol-based isolation boundaries, such as injecting an asynchronous service into a view model. An implementation may be an actor, but the protocol should state the operations needed by clients rather than expose unnecessary storage details.

SwiftUI demonstrates protocol-oriented and result-builder-based design, while UIKit continues to demonstrate delegation and class inheritance. Professional iOS development therefore requires judgment rather than loyalty to one style. The best design uses protocols, generics, classes, structures, actors, and composition according to the problem’s actual requirements.

Chapter Summary

Protocols define contracts that can be adopted by classes, structures, and enumerations. Protocol extensions supply reusable default behavior, while associated types describe type relationships without fixing concrete types. Delegation uses class-bound protocols and weak references to separate responsibilities safely.

Generics provide reusable, statically checked functions and types. Constraints and where clauses express the operations and relationships an algorithm requires. Protocol composition combines capabilities. Opaque types (some) hide a concrete implementation while preserving its identity, whereas existential types (any) permit values of varying conforming types.

Protocol-oriented design favors composition and capability-based abstraction. Inheritance remains appropriate for stable class hierarchies, shared identity, and lifecycle behavior. Effective Swift design balances both approaches, uses narrow contracts, respects concurrency and ownership, and avoids abstractions that do not provide practical value.

Key Terms

Protocol: A contract specifying requirements for conforming types.

Conformance: The condition in which a type satisfies a protocol’s requirements.

Protocol extension: An extension that adds behavior or requirements-related utilities to a protocol.

Default implementation: Behavior supplied by a protocol extension.

Delegation: Assigning a responsibility to another object through a protocol.

Class-bound protocol: A protocol restricted to class instances, commonly declared with AnyObject.

Protocol composition: A combined requirement written with &.

Associated type: A placeholder type declared by a protocol.

Generic: Code parameterized by one or more types.

Generic constraint: A protocol, superclass, or type relationship required of a generic parameter.

where clause: Syntax that expresses additional generic or extension constraints.

Existential type: A runtime value represented as any Protocol.

Opaque type: A hidden concrete type represented as some Protocol.

Type erasure: Hiding a concrete type behind a common interface.

Value type: A type whose instances are copied by value, such as a structure or enumeration.

Reference type: A class or actor type whose instances have identity and reference semantics.

Static dispatch: Selection of an implementation based primarily on compile-time information.

Dynamic dispatch: Selection of an implementation at runtime.

Capability: A focused behavior or responsibility a type can provide.

Review Questions

Short Answer Questions

1. What is the purpose of a Swift protocol?
2. Why might a delegate protocol be restricted to AnyObject?
3. What problem does an associated type solve?
4. State one difference between some P and any P.
5. Why are generic constraints useful?

Long Answer Questions

1. Explain how protocol extensions provide reuse and describe the dispatch issue involving methods that are not protocol requirements.
2. Compare protocol-oriented design and class inheritance using at least four criteria.
3. Explain how a generic repository with an associated Item type preserves type safety.
4. Describe how delegation can reduce coupling in an iOS application.
5. Discuss when value types, classes, and actors might be selected in a protocol-based design.

Analytical / Application Questions

1. Design protocols for a weather application that separates weather retrieval, caching, and presentation. Explain which methods belong in each protocol.
2. A function accepts any Repository, but the caller needs to know the repository’s item type. Explain why this may be problematic and propose a generic alternative.
3. A collection-view cell displays images from URLs and sometimes shows an old image after reuse. Analyze the lifecycle problem and propose a protocol-based, cancellable design.

Multiple Choice Questions with Answers

Question 1

Which declaration best expresses a capability that can be adopted by a structure, class, or enumeration?

A. A protocol

B. A superclass

C. A stored property

D. A deinitializer

Correct Answer: A. A protocol

Question 2

Why is a delegate property commonly declared weak when its protocol is class-bound?

A. To make the delegate immutable

B. To prevent a retain cycle

C. To enable generic specialization

D. To permit value-type adoption

Correct Answer: B. To prevent a retain cycle

Question 3

What does an associated type provide in a protocol?

A. A stored property shared by all conforming types

B. A superclass for conforming classes

C. A placeholder for a related type

D. A runtime-only method implementation

Correct Answer: C. A placeholder for a related type

Question 4

Which syntax represents an existential protocol value in modern Swift?

A. some Codable

B. where Codable

C. associatedtype Codable

D. any Codable

Correct Answer: D. any Codable

Question 5

What is the principal advantage of a generic constraint such as T: Equatable?

A. It allows the compiler to use operations guaranteed by Equatable

B. It forces T to be a class

C. It removes all runtime storage

D. It makes every value reference-semantics based

Correct Answer: A. It allows the compiler to use operations guaranteed by Equatable

Question 6

What does a return type of some View communicate?

A. The caller may return any number of unrelated view types

B. The concrete return type is hidden but fixed by the implementation

C. The result is always an existential value

D. The function must return a class instance

Correct Answer: B. The concrete return type is hidden but fixed by the implementation

Question 7

Which statement about protocol composition is correct?

A. It requires the protocols to share a superclass

B. It creates a new stored object at runtime

C. It requires a value to satisfy multiple protocol contracts

D. It can be used only with enumerations

Correct Answer: C. It requires a value to satisfy multiple protocol contracts

Question 8

In the cache example, why must the key type conform to Hashable?

A. The cache uses the key in a dictionary

B. Hashable makes the value conform to Codable

C. Hashable prevents all concurrency problems

D. The protocol requires every key to be a class

Correct Answer: A. The cache uses the key in a dictionary

Question 9

Which approach best preserves the relationship between a repository and its associated Item type?

A. Passing the repository as an unrelated String

B. Using a generic parameter constrained to Repository

C. Converting every item to AnyObject

D. Removing the associated type

Correct Answer: B. Using a generic parameter constrained to Repository

Question 10

Which design is most characteristic of protocol-oriented programming?

A. A single deep superclass hierarchy for all behavior

B. Capabilities expressed through small protocols and composition

C. Global mutable state shared by every type

D. Using inheritance whenever two types share one method

Correct Answer: B. Capabilities expressed through small protocols and composition