Why protocol-oriented design matters in Swift - See It in Action

Why protocol-oriented design matters

📖 Scenario: Imagine you are building a simple app to manage different types of vehicles. Each vehicle can start and stop, but they do these actions differently. You want a clean way to organize this behavior so you can add more vehicle types easily in the future.

🎯 Goal: You will create a protocol to define common vehicle actions, then make different vehicle types conform to this protocol. This shows why protocol-oriented design helps keep code simple and flexible.

📋 What You'll Learn

Create a protocol called Vehicle with two methods: start() and stop()

Create a struct called Car that conforms to Vehicle and implements start() and stop()

Create a struct called Bicycle that conforms to Vehicle and implements start() and stop()

Create an array called vehicles containing one Car and one Bicycle

Use a for loop to call start() and stop() on each vehicle in the vehicles array

Print messages inside each start() and stop() method to show which vehicle is starting or stopping

💡 Why This Matters

🌍 Real World

Protocol-oriented design is used in apps to organize code so different objects can share behavior without repeating code. For example, many types of vehicles or UI elements can follow the same protocol to simplify how the app controls them.

💼 Career

Understanding protocol-oriented design is important for Swift developers because it helps write clean, reusable, and flexible code. Many iOS apps and frameworks use protocols to manage complex behaviors in a simple way.

1

Create the Vehicle protocol

Create a protocol called Vehicle with two methods: start() and stop().

Swift

// Create the Vehicle protocol with start() and stop() methods
// Your code here

Hint

Protocols define a blueprint of methods. Use protocol Vehicle {} and add func start() and func stop() inside.

2

Create Car and Bicycle structs conforming to Vehicle

Create a struct called Car that conforms to Vehicle and implements start() and stop() methods. Then create a struct called Bicycle that also conforms to Vehicle and implements start() and stop() methods.

Swift

protocol Vehicle {
    func start()
    func stop()
}

// Create struct Car conforming to Vehicle
// Create struct Bicycle conforming to Vehicle
// Your code here

Hint

Use struct Car: Vehicle {} and inside add func start() and func stop() with print statements. Do the same for Bicycle.

3

Create an array of vehicles

Create an array called vehicles containing one Car() and one Bicycle().

Swift

protocol Vehicle {
    func start()
    func stop()
}

struct Car: Vehicle {
    func start() {
        print("Car is starting")
    }
    func stop() {
        print("Car is stopping")
    }
}

struct Bicycle: Vehicle {
    func start() {
        print("Bicycle is starting")
    }
    func stop() {
        print("Bicycle is stopping")
    }
}

// Create an array called vehicles with Car() and Bicycle()
// Your code here

Hint

Use let vehicles: [Vehicle] = [Car(), Bicycle()] to create the array.

4

Use a loop to start and stop all vehicles

Use a for loop with variable vehicle to iterate over vehicles. Inside the loop, call vehicle.start() and vehicle.stop(). Print the output.

Swift

protocol Vehicle {
    func start()
    func stop()
}

struct Car: Vehicle {
    func start() {
        print("Car is starting")
    }
    func stop() {
        print("Car is stopping")
    }
}

struct Bicycle: Vehicle {
    func start() {
        print("Bicycle is starting")
    }
    func stop() {
        print("Bicycle is stopping")
    }
}

let vehicles: [Vehicle] = [Car(), Bicycle()]

// Use a for loop to call start() and stop() on each vehicle
// Your code here

Hint

Use for vehicle in vehicles { vehicle.start(); vehicle.stop() } to run the methods on each vehicle.

Practice

1. What is the main benefit of using protocols in Swift's protocol-oriented design?

easy

A. They make the code run faster.

B. They store data like variables.

C. They replace classes completely.

D. They allow different types to share common behavior.

Solution

1. Step 1: Understand what protocols do

   Protocols define a set of behaviors that many types can adopt and share.

2. Step 2: Identify the main benefit

   This sharing of behavior helps make code reusable and flexible.

3. Final Answer:

   They allow different types to share common behavior. -> Option D

4. Quick Check:

   Protocols = shared behavior [OK]

Hint: Protocols share behavior across types, not data storage [OK]

Common Mistakes:

• Thinking protocols speed up code execution
• Confusing protocols with classes
• Believing protocols store data

2. Which of the following is the correct way to declare a protocol in Swift?

easy

A. struct Vehicle: protocol { func drive() }

B. class Vehicle { func drive() }

C. protocol Vehicle { func drive() }

D. func protocol Vehicle() { drive() }

Solution

1. Step 1: Recall Swift protocol syntax

   Protocols are declared using the keyword 'protocol' followed by the name and curly braces.

2. Step 2: Match the correct syntax

   protocol Vehicle { func drive() } correctly uses 'protocol Vehicle { func drive() }'. Other options misuse keywords or structure.

3. Final Answer:

   protocol Vehicle { func drive() } -> Option C

4. Quick Check:

   Protocol declaration = protocol keyword + name + braces [OK]

Hint: Protocols start with 'protocol' keyword, not 'class' or 'func' [OK]

Common Mistakes:

• Using 'class' instead of 'protocol'
• Trying to inherit protocol with ':' in struct incorrectly
• Writing 'func protocol' which is invalid

3. Consider this Swift code:

protocol Greetable { func greet() -> String }

struct Person: Greetable {
  func greet() -> String { "Hello!" }
}

let p = Person()
print(p.greet())

What will be the output?

medium

A. Hello!

B. greet()

C. Error: Missing function implementation

D. nil

Solution

1. Step 1: Check protocol conformance

   Person struct implements the greet() method required by Greetable.

2. Step 2: Understand the print output

   Calling p.greet() returns "Hello!", which is printed.

3. Final Answer:

   Hello! -> Option A

4. Quick Check:

   Implemented method returns "Hello!" [OK]

Hint: Implemented protocol methods run normally when called [OK]

Common Mistakes:

• Assuming protocol methods print their name
• Expecting runtime error without implementation
• Thinking print outputs nil if no return

4. What is wrong with this Swift code?

protocol Drawable {
  func draw()
}

struct Circle: Drawable {
  // Missing draw() implementation
}

let c = Circle()

medium

A. Circle must implement draw() or code won't compile.

B. Circle can omit draw() because it's a struct.

C. Protocol Drawable should not have functions.

D. Circle should be a class, not a struct.

Solution

1. Step 1: Check protocol requirements

   Drawable requires any conforming type to implement draw().

2. Step 2: Verify Circle implementation

   Circle does not implement draw(), so it violates the protocol.

3. Final Answer:

   Circle must implement draw() or code won't compile. -> Option A

4. Quick Check:

   Protocol methods must be implemented [OK]

Hint: All protocol methods must be implemented to compile [OK]

Common Mistakes:

• Thinking structs can skip protocol methods
• Believing protocols can't have functions
• Confusing struct vs class requirements

5. You want to design a system where multiple types like Car and Bicycle can be "startable" with a start() method. Using protocol-oriented design, which approach is best?

hard

A. Write separate start() functions outside the types for each vehicle.

B. Create a protocol Startable with start() and have both types conform to it.

C. Make Car and Bicycle subclasses of a common class with start() method.

D. Use global variables to track if Car or Bicycle started.

Solution

1. Step 1: Identify shared behavior

   Both Car and Bicycle need a start() method, which is shared behavior.

2. Step 2: Apply protocol-oriented design

   Defining a Startable protocol with start() and making both types conform promotes reuse and flexibility.

3. Step 3: Compare other options

   Subclassing limits flexibility; separate functions or globals reduce clarity and reuse.

4. Final Answer:

   Create a protocol Startable with start() and have both types conform to it. -> Option B

5. Quick Check:

   Protocol for shared behavior = best design [OK]

Hint: Use protocols to share behavior across unrelated types [OK]

Common Mistakes:

• Using class inheritance when unrelated types
• Writing separate functions instead of protocol
• Using global state instead of behavior abstraction