POP vs OOP decision patterns in Swift - Practice Questions

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of protocol extension vs class inheritance

Consider the following Swift code. What will be printed when calling dog.speak()?

Swift

protocol Animal {
    func speak()
}

extension Animal {
    func speak() {
        print("Animal sound")
    }
}

class Dog: Animal {
    func speak() {
        print("Bark")
    }
}

let dog: Animal = Dog()
dog.speak()

A Animal sound

B No output

C Compilation error

D Bark

💡 Hint

Think about how protocol requirements and class methods interact in Swift.

The class Dog implements the speak() method, which overrides the protocol extension default. When called on a Dog instance typed as Animal, the Dog's speak() is used, printing "Bark".

🧠 Conceptual

intermediate

Choosing between POP and OOP for code reuse

Which statement best describes when to prefer Protocol-Oriented Programming (POP) over Object-Oriented Programming (OOP) in Swift?

A Use OOP when you want to avoid code reuse and write separate implementations.

B Use POP when you want to share behavior across unrelated types without inheritance.

C Use OOP when you want to avoid using protocols and prefer structs only.

D Use POP only when you need to create a class hierarchy with shared state.

💡 Hint

Think about how protocols allow behavior sharing without inheritance.

POP is ideal for sharing behavior across different types without forcing them into a class hierarchy. It uses protocols and protocol extensions to provide default implementations.

🔧 Debug

advanced

Why does this OOP code cause a runtime error?

Examine the Swift code below. Why does calling vehicle.drive() cause a runtime crash?

Swift

class Vehicle {
    func drive() {
        fatalError("Must override")
    }
}

class Car: Vehicle {
}

let vehicle: Vehicle = Car()
vehicle.drive()

A Because Car is not marked as final, it cannot override methods.

B Because Vehicle is a class, it cannot be instantiated directly.

C Because Car does not override drive(), calling drive() calls fatalError causing a crash.

D Because drive() is not marked as @objc, it cannot be called dynamically.

💡 Hint

Look at the method drive() in Vehicle and what happens if a subclass does not override it.

The base class Vehicle's drive() method calls fatalError, which crashes the program. Since Car does not override drive(), calling drive() on a Car instance calls the base method and crashes.

📝 Syntax

advanced

Which code correctly implements protocol conformance with default implementation?

Given the protocol Flyable with a default fly() method, which option compiles and prints "Flying" when calling bird.fly()?

Swift

protocol Flyable {
    func fly()
}

extension Flyable {
    func fly() {
        print("Flying")
    }
}

struct Bird: Flyable {
    // Implementation here
}

let bird = Bird()
bird.fly()

A struct Bird: Flyable {}

B struct Bird: Flyable { func fly() { print("Flying") } }

C struct Bird: Flyable { func fly() -> String { "Flying" } }

D struct Bird: Flyable { func fly() -> Void { print("Flying") } }

💡 Hint

Check if Bird needs to implement fly() explicitly when protocol extension provides it.

Option A compiles and uses the default fly() from the protocol extension, printing "Flying". Option A also compiles but is redundant. Option A has wrong return type causing errors.

🚀 Application

expert

Deciding design pattern for a shape drawing app

You are designing a Swift app to draw shapes: circles, squares, and triangles. Each shape can be drawn and resized. You want to add new shapes easily and share drawing code without forcing a class hierarchy. Which approach fits best?

A Use Protocol-Oriented Programming with a Shape protocol defining draw() and resize(), and provide default implementations via protocol extensions.

B Use Object-Oriented Programming with a base Shape class and subclasses for each shape overriding draw() and resize().

C Use structs without protocols and duplicate draw() and resize() code in each shape struct.

D Use global functions for draw() and resize() that take any shape type as parameters.

💡 Hint

Think about flexibility and code reuse without inheritance.

POP allows adding new shapes easily by conforming to the Shape protocol. Protocol extensions enable sharing default behavior without class inheritance, making the design flexible and extensible.