Why protocol-oriented design matters in Swift - Why It Works This Way

Overview - Why protocol-oriented design matters

What is it?

Protocol-oriented design is a way to organize code by focusing on protocols, which are like blueprints for what things can do. Instead of building everything around classes, you define behaviors and then make different types follow those behaviors. This helps create flexible and reusable code that works well with many kinds of objects.

Why it matters

Without protocol-oriented design, code can become rigid and hard to change because it relies too much on specific classes and inheritance. Protocols let you write code that works with any type that follows the rules, making your programs easier to extend and maintain. This means faster development and fewer bugs in real projects.

Where it fits

Before learning protocol-oriented design, you should understand basic Swift syntax, classes, and structs. After this, you can explore advanced Swift features like generics, protocol extensions, and functional programming patterns.

Mental Model

Core Idea

Protocol-oriented design means defining what something can do first, then making many different things follow those rules to share behavior.

Think of it like...

It's like creating a recipe for a dish and then letting different cooks make their own versions using that recipe. The recipe sets the rules, but each cook can add their own style.

┌───────────────┐
│   Protocol    │
│ (Blueprint)   │
└──────┬────────┘
       │
┌──────┴───────┐   ┌─────────────┐
│   Struct A   │   │   Class B   │
│ (Follows     │   │ (Follows    │
│  Protocol)   │   │  Protocol)  │
└──────────────┘   └─────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Protocols as Blueprints

Concept: Protocols define a set of rules or behaviors that types can follow without specifying how they do it.

In Swift, a protocol lists methods or properties that a type must implement. For example, a protocol 'Drivable' might require a 'drive()' method. Any type that says it is 'Drivable' promises to have that method.

Result

You can write code that works with any 'Drivable' type, no matter if it's a car, bike, or robot.

Understanding protocols as contracts helps you think about what behaviors matter, not how they are done.

2

Foundation

Difference Between Classes and Protocols

Concept: Classes define concrete objects with data and behavior, while protocols only define behavior without data or implementation.

Classes can inherit from other classes and hold data, but protocols only say what methods or properties must exist. This means protocols are more flexible and can be adopted by many types, including structs and enums.

Result

You can use protocols to share behavior across different kinds of types, not just classes.

Knowing this difference opens the door to more flexible and reusable code designs.

3

Intermediate

Protocol Extensions Add Default Behavior

🤔Before reading on: do you think protocols can provide default method implementations? Commit to yes or no.

Concept: Protocol extensions let you add default code for protocol methods, so types don’t always have to write their own.

Swift allows you to write code inside a protocol extension that provides default behavior. For example, if 'Drivable' has a 'drive()' method, you can give a default implementation so all types get it unless they override.

Result

This reduces repeated code and lets you add new features to many types at once.

Knowing protocol extensions lets you build flexible, shared behavior without forcing every type to write the same code.

4

Intermediate

Using Protocols for Flexible APIs

🤔Before reading on: do you think protocols help make APIs that work with many types or just one? Commit to your answer.

Concept: Protocols let you write functions and APIs that accept any type following a protocol, making your code more adaptable.

Instead of writing a function that only accepts a 'Car' class, you write one that accepts any 'Drivable'. This means your function works with cars, bikes, or any future types that conform.

Result

Your code becomes easier to extend and maintain as new types appear.

Understanding this helps you design code that is open to change but closed to modification, a key software principle.

5

Advanced

Protocol-Oriented Design vs Object-Oriented Design

🤔Before reading on: do you think protocol-oriented design replaces or complements object-oriented design? Commit to your answer.

Concept: Protocol-oriented design focuses on behavior and composition, while object-oriented design focuses on inheritance and data hierarchy.

In protocol-oriented design, you build small protocols for behaviors and combine them, avoiding deep class inheritance trees. This leads to more modular and testable code.

Result

You get code that is easier to change and less prone to bugs caused by complex inheritance.

Knowing the difference helps you choose the right approach for your project and avoid common pitfalls of inheritance.

6

Expert

How Protocol-Oriented Design Enables Swift’s Power

🤔Before reading on: do you think protocol-oriented design is just a style or a core part of Swift’s design? Commit to your answer.

Concept: Swift’s standard library and language features are built around protocols, making protocol-oriented design central to writing idiomatic Swift.

Many Swift features like generics, collections, and operators rely on protocols. Protocol extensions and associated types let you write highly generic and efficient code that works across many types.

Result

Mastering protocol-oriented design unlocks the full power of Swift and leads to safer, faster, and cleaner code.

Understanding this reveals why Apple designed Swift this way and how to write code that fits naturally with the language.

Under the Hood

Protocols in Swift are implemented using a mechanism called 'witness tables' that map protocol requirements to the actual methods of a conforming type at runtime. This allows the compiler to call the correct method even if the exact type is unknown. Protocol extensions provide default implementations that are statically dispatched unless overridden, improving performance and flexibility.

Why designed this way?

Swift was designed to combine the safety and performance of static typing with the flexibility of dynamic behavior. Protocol-oriented design avoids the pitfalls of deep inheritance hierarchies common in other languages by promoting composition over inheritance. This design allows Swift to be both expressive and efficient.

┌───────────────┐
│   Protocol    │
│ Requirements  │
└──────┬────────┘
       │
┌──────┴─────────────┐
│ Witness Table (maps │
│ protocol to methods)│
└──────┬─────────────┘
       │
┌──────┴─────────────┐
│ Concrete Type's     │
│ Method Implementations│
└─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do protocols in Swift hold data like classes? Commit to yes or no.

Common Belief: Protocols can store data just like classes or structs.

Reality: Protocols only define behavior (methods and properties) but do not store data themselves.

Why it matters: Thinking protocols hold data leads to confusion about where state lives and can cause design mistakes.

Quick: Can protocol extensions override methods in conforming types? Commit to yes or no.

Common Belief: Protocol extensions can override methods implemented by conforming types.

Reality: Methods implemented by conforming types always take precedence over protocol extension defaults; extensions provide fallback only.

Why it matters: Misunderstanding this can cause bugs where you expect an extension method to run but the type’s method runs instead.

Quick: Does protocol-oriented design eliminate the need for classes? Commit to yes or no.

Common Belief: Protocol-oriented design means you should never use classes.

Reality: Classes are still useful for reference semantics and inheritance; protocol-oriented design complements, not replaces, classes.

Why it matters: Ignoring classes can lead to inefficient or awkward code when reference behavior is needed.

Quick: Are protocols always slower than classes because of dynamic dispatch? Commit to yes or no.

Common Belief: Using protocols always makes code slower due to dynamic dispatch.

Reality: Swift uses static dispatch for many protocol calls, especially with protocol extensions, so performance can be as good as or better than classes.

Why it matters: Believing protocols are slow may discourage their use, missing out on their design benefits.

Expert Zone

1

Protocol composition allows combining multiple protocols into one requirement, enabling very flexible and precise type constraints.

2

Associated types in protocols let you define placeholders for types that conforming types specify, enabling powerful generic programming.

3

Protocol-oriented design encourages value types (structs/enums) over reference types (classes), improving safety by avoiding shared mutable state.

When NOT to use

Avoid protocol-oriented design when you need complex inheritance hierarchies with shared mutable state or identity semantics; in those cases, classical object-oriented design with classes is more appropriate.

Production Patterns

In real-world Swift projects, protocol-oriented design is used to build modular components, define clear interfaces for testing with mocks, and create reusable libraries that work with many types without code duplication.

Connections

Interface Segregation Principle (Software Engineering)

Protocol-oriented design builds on this principle by encouraging small, focused protocols rather than large, monolithic ones.

Knowing this principle helps you design protocols that are easier to implement and maintain, improving code quality.

Composition over Inheritance (Software Design)

Protocol-oriented design embodies this idea by favoring behavior composition through protocols instead of class inheritance.

Understanding this connection helps you avoid common pitfalls of deep inheritance trees and write more flexible code.

Biological Taxonomy

Both organize entities by shared characteristics but differ: taxonomy uses hierarchical inheritance, while protocol-oriented design uses shared behaviors without strict hierarchy.

Seeing this contrast clarifies why protocol-oriented design avoids rigid hierarchies, allowing more adaptable classification.

Common Pitfalls

#1 Trying to store data directly in protocols.

Wrong approach:

protocol Vehicle {
var speed: Int = 0 // Error: Protocols can't store data
func drive()
}

Correct approach:

protocol Vehicle {
var speed: Int { get set } // Protocol only requires property, no storage
func drive()
}

Root cause:

Misunderstanding that protocols define behavior, not data storage.

#2 Expecting protocol extension methods to override conforming type methods.

Wrong approach:

extension Drivable {
func drive() { print("Default drive") }
}

struct Car: Drivable {
func drive() { print("Car driving") }
}

let c = Car()
c.drive() // Expects 'Default drive' but prints 'Car driving'

Correct approach:

Understand that conforming type methods always override protocol extension defaults; design accordingly.

Root cause:

Confusing protocol extension default implementations with method overriding.

#3 Using classes everywhere and ignoring protocols for flexibility.

Wrong approach:

class Car {
func drive() { print("Car driving") }
}

func start(vehicle: Car) { vehicle.drive() }

Correct approach:

protocol Drivable {
func drive()
}

func start(vehicle: Drivable) { vehicle.drive() }

Root cause:

Not leveraging protocols to write flexible, reusable code.

Key Takeaways

Protocols define what behaviors types must have without specifying how, enabling flexible code design.

Protocol-oriented design encourages composition of behaviors over inheritance, leading to more modular and maintainable code.

Swift’s protocol extensions provide default behavior, reducing code duplication and increasing reuse.

Understanding protocol-oriented design unlocks the full power of Swift’s language features and standard library.

Misunderstanding protocols can lead to design mistakes; mastering them improves code safety, flexibility, and performance.