Why protocol-oriented design matters in Swift - Quick Recap

Recall & Review

beginner

What is protocol-oriented design in Swift?

Protocol-oriented design is a way of writing code where you define blueprints (protocols) for what things should do, and then make different types follow those blueprints. It helps organize code by focusing on behavior rather than specific classes.

beginner

Why does protocol-oriented design improve code flexibility?

Because protocols define what actions are possible without fixing how they are done, you can change or add new types easily without rewriting existing code. This makes your program more adaptable to change.

intermediate

How does protocol-oriented design help with code reuse?

You can write default behavior in protocol extensions that many types can share. This means you write code once and use it in many places, saving time and reducing mistakes.

intermediate

What problem does protocol-oriented design solve compared to class inheritance?

Class inheritance can be rigid and cause tight coupling, making changes hard. Protocol-oriented design avoids this by focusing on what things can do, not what they are, allowing more flexible and modular code.

beginner

Give a real-life example of protocol-oriented design.

Think of a 'Vehicle' protocol that says all vehicles can 'start' and 'stop'. Cars, bikes, and boats can all follow this protocol but implement these actions differently. This way, you can treat them all as vehicles without worrying about their details.

What does a protocol in Swift define?

A A concrete class implementation

B A blueprint of methods and properties

C A variable storage location

D A user interface layout

Protocols define a blueprint of methods and properties that conforming types must implement.

How does protocol-oriented design help when adding new types?

A You can add new types without changing existing code

B You must rewrite all existing code

C It forces you to use inheritance

D It prevents code reuse

Protocols allow new types to conform without changing existing code, improving flexibility.

What feature of Swift allows sharing default behavior in protocols?

A Enums

B Class inheritance

C Structs

D Protocol extensions

Protocol extensions let you provide default implementations for protocol methods.

Why is protocol-oriented design preferred over class inheritance in Swift?

A It is less flexible

B It creates tighter coupling

C It focuses on behavior, not type hierarchy

D It requires more code

Protocol-oriented design focuses on what things can do, making code more modular and flexible.

Which of these is a benefit of protocol-oriented design?

A Easy to reuse and extend code

B Hard to test code

C Only works with classes

D Rigid code structure

Protocol-oriented design makes code easier to reuse and extend.

Explain in your own words why protocol-oriented design matters in Swift programming.

Think about how protocols help organize code and make it easier to change.

Describe a simple example where protocol-oriented design improves your code compared to using only classes.

Imagine different types that share some actions but are not related by class.

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