Protocol requirements (methods and properties) in Swift - Deep Dive

Overview - Protocol requirements (methods and properties)

What is it?

A protocol in Swift is like a promise that a type makes to provide certain methods and properties. Protocol requirements are the specific methods and properties that any type adopting the protocol must implement. These requirements define what the type can do or what information it must hold, without saying how it does it. This helps different types work together by agreeing on a common set of features.

Why it matters

Protocols with requirements let programmers write flexible and reusable code. Without them, every type would need its own unique code, making programs harder to maintain and extend. Protocols solve the problem of different types needing to behave similarly, allowing code to work with any type that meets the requirements. This makes apps more reliable and easier to grow.

Where it fits

Before learning protocol requirements, you should understand basic Swift types, functions, and properties. After mastering protocols, you can explore protocol extensions, generics, and advanced design patterns like delegation and dependency injection.

Mental Model

Core Idea

A protocol requirement is a contract that says: any type that adopts this protocol must provide these methods and properties.

Think of it like...

Think of a protocol like a job description. It lists the tasks (methods) and tools (properties) a worker must have. Anyone hired for the job promises to do those tasks and have those tools, but how they do it is up to them.

┌─────────────────────────────┐
│         Protocol            │
│ ┌─────────────────────────┐ │
│ │ Requirements:           │ │
│ │ - methodA()             │ │
│ │ - propertyB (get/set)   │ │
│ └─────────────────────────┘ │
└─────────────┬───────────────┘
              │
      ┌───────┴────────┐
      │                │
┌─────────────┐  ┌─────────────┐
│ Type1       │  │ Type2       │
│ implements  │  │ implements  │
│ methodA()   │  │ methodA()   │
│ propertyB   │  │ propertyB   │
└─────────────┘  └─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Protocol Basics

Concept: Protocols define a blueprint of methods and properties without implementation.

In Swift, a protocol lists methods and properties that a type must have. For example, a protocol named 'Vehicle' might require a method 'drive()' and a property 'speed'. The protocol itself does not say how these work, just that they must exist.

Result

You know how to declare a protocol with method and property requirements.

Understanding that protocols only describe what must exist, not how, is key to grasping their role in flexible code design.

2

Foundation

Methods and Properties in Protocols

Concept: Protocols can require both methods (functions) and properties, including whether properties are readable or writable.

Protocols can require methods like 'start()' and properties like 'name' with get or set access. For example: protocol Animal { func sound() -> String var numberOfLegs: Int { get } } Here, any type adopting 'Animal' must have a 'sound' method and a readable 'numberOfLegs' property.

Result

You can specify method and property requirements with read-only or read-write access.

Knowing how to require properties with get or set controls how flexible or strict the adopting types must be.

3

Intermediate

Implementing Protocol Requirements

🤔Before reading on: do you think a class must implement all protocol methods exactly as declared, or can it skip some? Commit to your answer.

Concept: Types adopting a protocol must implement all required methods and properties exactly as specified.

When a class, struct, or enum adopts a protocol, it promises to provide all required methods and properties. For example: protocol Greetable { func greet() } struct Person: Greetable { func greet() { print("Hello!") } } If 'Person' misses 'greet()', the code won't compile.

Result

The compiler enforces that all protocol requirements are met.

Understanding that protocols enforce a strict contract prevents runtime errors and ensures consistent behavior.

4

Intermediate

Property Requirements: Gettable vs Gettable & Settable

🤔Before reading on: do you think a protocol requiring a gettable property allows the adopter to make it read-write? Commit to your answer.

Concept: Protocols can require properties to be readable only or both readable and writable, affecting how adopters implement them.

A protocol can require a property like 'var age: Int { get }' which means the adopter must provide a readable property. The adopter can make it read-write if desired. But if the protocol requires 'var age: Int { get set }', the adopter must allow both reading and writing. Example: protocol PersonProtocol { var name: String { get set } } class Person: PersonProtocol { var name: String = "" } Here, 'name' is read-write as required.

Result

You understand how property access requirements affect implementation flexibility.

Knowing the difference between get and get set in protocols helps design clear and safe interfaces.

5

Intermediate

Using Protocols with Classes and Value Types

Concept: Both classes and value types (structs, enums) can adopt protocols and implement requirements, but property behavior differs slightly.

Classes can implement protocol properties as stored or computed properties. Structs and enums also implement them but must be careful with mutability. For example, a struct implementing a settable property must mark the property as 'var' and methods that modify it as 'mutating'. Example: protocol Toggleable { var isOn: Bool { get set } mutating func toggle() } struct LightSwitch: Toggleable { var isOn = false mutating func toggle() { isOn.toggle() } }

Result

You can implement protocol requirements correctly in both classes and value types.

Understanding mutability rules in value types is essential to correctly fulfill protocol requirements.

6

Advanced

Protocol Requirements with Initializers

🤔Before reading on: do you think protocols can require initializers? Commit to your answer.

Concept: Protocols can require initializers, forcing adopters to provide specific ways to create instances.

You can require an initializer in a protocol like this: protocol Initializable { init(value: Int) } A class or struct adopting this must implement that initializer: struct Number: Initializable { var value: Int init(value: Int) { self.value = value } } This ensures all adopters can be created in a consistent way.

Result

You know how to require and implement initializers in protocols.

Requiring initializers in protocols helps enforce consistent creation patterns across types.

7

Expert

Protocol Requirements and Associated Types

🤔Before reading on: do you think protocols can require types to specify other types? Commit to your answer.

Concept: Protocols can declare associated types as placeholders that adopters must specify, adding flexibility to requirements.

An associated type is a placeholder type used in a protocol. For example: protocol Container { associatedtype Item var count: Int { get } subscript(i: Int) -> Item { get } } A type adopting 'Container' must specify what 'Item' is. For example: struct IntStack: Container { var items = [Int]() var count: Int { items.count } subscript(i: Int) -> Int { items[i] } typealias Item = Int } This allows protocols to work with generic types safely.

Result

You understand how associated types extend protocol requirements for generic programming.

Knowing associated types unlocks powerful abstractions and reusable code patterns in Swift.

Under the Hood

At runtime, Swift uses protocol witness tables to map protocol requirements to the actual implementations in the adopting type. When a method or property is called through a protocol reference, Swift looks up the correct function or property getter/setter in this table. This allows different types to be used interchangeably as long as they fulfill the protocol contract, enabling polymorphism.

Why designed this way?

Swift protocols were designed to provide flexible, type-safe interfaces without forcing inheritance. The use of witness tables allows efficient dynamic dispatch while preserving performance. This design balances safety, flexibility, and speed, unlike older languages that rely heavily on class inheritance or duck typing.

┌───────────────────────────────┐
│          Protocol Type         │
│ ┌───────────────────────────┐ │
│ │ Protocol Requirements List │ │
│ └─────────────┬─────────────┘ │
└───────────────│───────────────┘
                │
       ┌────────┴─────────┐
       │ Witness Table    │
       │ (maps methods &  │
       │  properties)     │
       └────────┬─────────┘
                │
       ┌────────┴─────────┐
       │ Concrete Type    │
       │ Implementations  │
       └──────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Can a type adopt a protocol without implementing all its requirements? Commit to yes or no.

Common Belief: A type can adopt a protocol and implement only some of its requirements, filling in the rest later.

Reality: A type must implement all protocol requirements immediately; otherwise, the code will not compile.

Why it matters: Believing partial implementation is allowed leads to compile errors and confusion about protocol contracts.

Quick: Does a protocol requirement force a property to be stored? Commit to yes or no.

Common Belief: Protocol properties must be stored properties in the adopting type.

Reality: Protocol properties can be stored or computed; the protocol only requires the presence of getters and/or setters.

Why it matters: Misunderstanding this limits design flexibility and leads to unnecessary stored properties.

Quick: Can a protocol requirement specify access control like private or public? Commit to yes or no.

Common Belief: Protocol requirements can specify access control levels like private or public for methods and properties.

Reality: Protocols only specify the interface; access control is determined by the adopting type and cannot be private in the protocol itself.

Why it matters: Confusing this causes errors when trying to hide protocol methods or properties, leading to design mistakes.

Quick: Can protocols require stored properties? Commit to yes or no.

Common Belief: Protocols can require stored properties to be present in adopting types.

Reality: Protocols cannot require stored properties; they only require that properties with certain accessors exist, which can be computed or stored.

Why it matters: This misconception leads to frustration when trying to enforce storage, which protocols do not support.

Expert Zone

1

Protocol requirements can be satisfied by computed properties, allowing dynamic behavior while fulfilling the contract.

2

When multiple protocols require the same method or property, Swift merges these requirements, but conflicts must be resolved carefully.

3

Protocols with associated types cannot be used as types directly without specifying the associated type, which affects how you design APIs.

When NOT to use

Protocols are not ideal when you need to share stored property implementations or state; in such cases, class inheritance or protocol extensions with default implementations might be better. Also, protocols with associated types can be limiting when you want to use them as generic constraints but not as concrete types.

Production Patterns

In production, protocols with requirements are used to define clear interfaces for components like data sources, delegates, and services. They enable dependency injection and testing by allowing mock implementations. Protocol-oriented programming leverages these requirements to build modular, testable, and maintainable codebases.

Connections

Interfaces in Object-Oriented Programming

Protocols in Swift serve a similar role to interfaces in other languages like Java or C#, defining contracts without implementation.

Understanding protocols helps grasp how different languages enforce contracts and enable polymorphism.

Abstract Base Classes

Protocols differ from abstract base classes by not providing implementation or state, focusing purely on requirements.

Knowing this distinction clarifies when to use protocols versus inheritance for code reuse.

Contracts in Legal Agreements

Protocols act like legal contracts between parties, specifying obligations without dictating methods.

This cross-domain view highlights the importance of clear, enforceable agreements for cooperation.

Common Pitfalls

#1 Forgetting to implement all protocol requirements causes compile errors.

Wrong approach:

protocol Drawable {
func draw()
}

struct Circle: Drawable {
// forgot to implement draw()
}

Correct approach:

protocol Drawable {
func draw()
}

struct Circle: Drawable {
func draw() {
print("Drawing a circle")
}
}

Root cause:

Misunderstanding that all protocol requirements must be implemented immediately.

#2 Trying to declare a stored property in a protocol.

Wrong approach:

protocol Person {
var name: String = "" // error: protocols can't have stored properties
}

Correct approach:

protocol Person {
var name: String { get set }
}

Root cause:

Confusing protocol property requirements with stored property declarations.

#3 Implementing a get-only property when the protocol requires get and set.

Wrong approach:

protocol Vehicle {
var speed: Int { get set }
}

struct Car: Vehicle {
var speed: Int {
return 50
}
}

Correct approach:

protocol Vehicle {
var speed: Int { get set }
}

struct Car: Vehicle {
var speed: Int = 50
}

Root cause:

Not matching the property's mutability requirements in the protocol.

Key Takeaways

Protocol requirements define a clear contract of methods and properties that adopting types must implement.

Protocols separate the 'what' from the 'how', allowing flexible and reusable code across different types.

Property requirements specify whether properties must be readable or writable, guiding how types implement them.

All protocol requirements must be implemented exactly to satisfy the contract and compile successfully.

Advanced features like associated types and initializer requirements extend protocols' power for generic and consistent design.