Protocols & Extensions

Introduction

A protocol defines a blueprint of properties, methods, or other requirements that a type can conform to, without dictating how that type must be implemented. Combined with extensions — which let you add functionality to any existing type, even ones you don't own — protocols are the foundation of what Apple calls "protocol-oriented programming," a style the Swift standard library itself is built around.

This lesson covers defining and conforming to protocols, using protocols as types, adding functionality with extensions, and protocol extensions that supply default implementations.

Defining Protocols

A protocol lists requirements — properties and methods a conforming type must implement — but contains no implementation of its own.

protocol Vehicle {
    var wheels: Int { get }
    func describe() -> String
}

Conforming to Protocols

Any struct, class, or enum can conform to a protocol by implementing every requirement it lists. Multiple unrelated types can conform to the same protocol, each with its own implementation.

struct Car: Vehicle {
    var wheels: Int = 4
    func describe() -> String {
        "A car with \(wheels) wheels"
    }
}

struct Bicycle: Vehicle {
    var wheels: Int = 2
    func describe() -> String {
        "A bicycle with \(wheels) wheels"
    }
}

Protocols as Types

A protocol can be used as a type itself, letting you write code that works with any conforming type without caring what the concrete type actually is.

let vehicles: [Vehicle] = [Car(), Bicycle()]
for v in vehicles {
    print(v.describe())
}

Extensions Basics

An `extension` adds new functionality — computed properties, methods, initializers, and protocol conformance — to an existing type, without modifying its original source code.

extension Int {
    var isEven: Bool {
        self % 2 == 0
    }
    func squared() -> Int {
        self * self
    }
}

print(4.isEven)
print(5.squared())

Extending Existing Types

The example above extends `Int`, a type built into the Swift standard library that you don't own. This is one of the most useful features of extensions: you can add convenience functionality to types from the standard library, third-party frameworks, or Apple's own frameworks, without subclassing or wrapping them.

Protocol Extensions

You can also extend a protocol itself to provide a default implementation for one of its requirements (or add entirely new methods). Every conforming type gets the default implementation automatically, unless it provides its own.

protocol Greetable {
    var name: String { get }
}

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

struct User: Greetable {
    var name: String
}

print(User(name: "Zara").greet())

Protocol-Oriented Programming

Apple introduced the term "protocol-oriented programming" at WWDC 2015, describing a style where shared behavior is composed through small, focused protocols and protocol extensions rather than deep class inheritance hierarchies. The Swift standard library itself follows this pattern extensively — types like `Equatable`, `Comparable`, `Hashable`, and `Collection` are all protocols, not base classes, which is why both structs and classes can conform to the exact same shared behaviors.

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

You now understand how protocols and extensions let Swift share behavior flexibly across unrelated types. In the final lesson, you'll pull everything together with Swift best practices, error handling, memory management, and where to go next.