POP vs OOP decision patterns in Swift - When to Use Which

The Big Idea

Discover how choosing the right pattern can save your app from chaos and endless bugs!

The Scenario

Imagine building a simple app where you need to manage different types of users and their actions. You try to write all the code in one big class, mixing everything together.

The Problem

This approach quickly becomes messy and hard to change. Adding new user types or behaviors means rewriting big chunks of code, risking bugs and confusion.

The Solution

Using POP (Protocol-Oriented Programming) and OOP (Object-Oriented Programming) decision patterns helps organize your code clearly. You separate what things do (protocols) from how they do it (classes or structs), making your app easier to build and update.

Before vs After

✗ Before

class User {
  func action() {
    // all user actions mixed here
  }
}

✓ After

protocol Actionable {
  func action()
}

struct Admin: Actionable {
  func action() { /* admin action */ }
}

class Guest: Actionable {
  func action() { /* guest action */ }
}

What It Enables

This lets you add new behaviors or user types without breaking existing code, making your app flexible and robust.

Real Life Example

Think of a ride-sharing app where drivers and passengers have different actions. Using POP and OOP patterns helps you manage these roles cleanly and add new features easily.

Key Takeaways

Manual code mixing behaviors is hard to maintain.

POP and OOP separate roles and actions clearly.

This leads to easier updates and fewer bugs.

Practice

1. Which statement best describes the main difference between Protocol-Oriented Programming (POP) and Object-Oriented Programming (OOP) in Swift?

easy

A. POP focuses on protocols and structs, while OOP focuses on classes and inheritance.

B. POP uses only classes, and OOP uses only structs.

C. POP does not support code reuse, but OOP does.

D. OOP uses protocols, but POP does not.

Solution

1. Step 1: Understand POP and OOP basics

   POP uses protocols to define behavior and structs or classes to implement it. OOP uses classes and inheritance to share and override behavior.

2. Step 2: Compare the main focus of each paradigm

   POP emphasizes protocols and value types (structs), while OOP emphasizes classes and inheritance.

3. Final Answer:

   POP focuses on protocols and structs, while OOP focuses on classes and inheritance. -> Option A

4. Quick Check:

   POP = protocols & structs, OOP = classes & inheritance [OK]

Hint: POP = protocols + structs, OOP = classes + inheritance [OK]

Common Mistakes:

• Thinking POP uses only classes
• Believing OOP does not use protocols
• Assuming POP cannot reuse code

2. Which of the following Swift code snippets correctly declares a protocol and a struct conforming to it?

easy

A. protocol Vehicle { func drive() }; struct Car: Vehicle { var speed: Int = 0 }

B. class Vehicle { func drive() }; struct Car inherits Vehicle { func drive() { print("Driving") } }

C. protocol Vehicle { func drive() }; struct Car: Vehicle { func drive() { print("Driving") } }

D. protocol Vehicle { func drive() }; class Car: Vehicle { func drive() { print("Driving") } }

Solution

1. Step 1: Check protocol and struct syntax

   protocol Vehicle { func drive() }; struct Car: Vehicle { func drive() { print("Driving") } } correctly declares a protocol with a method and a struct conforming by implementing that method.

2. Step 2: Identify syntax errors in other options

   class Vehicle { func drive() }; struct Car inherits Vehicle { func drive() { print("Driving") } } uses invalid inheritance syntax for struct. protocol Vehicle { func drive() }; struct Car: Vehicle { var speed: Int = 0 } misses method requirement. protocol Vehicle { func drive() }; class Car: Vehicle { func drive() { print("Driving") } } uses class instead of struct.

3. Final Answer:

   protocol Vehicle { func drive() }; struct Car: Vehicle { func drive() { print("Driving") } } -> Option C

4. Quick Check:

   Protocol + struct with method implementation = protocol Vehicle { func drive() }; struct Car: Vehicle { func drive() { print("Driving") } } [OK]

Hint: Protocols declare methods; structs implement them with correct syntax [OK]

Common Mistakes:

• Using 'inherits' keyword with structs
• Not implementing all protocol methods
• Confusing class and struct declarations

3. What will be the output of the following Swift code?

protocol Greetable {
    func greet() -> String
}

class Person: Greetable {
    func greet() -> String {
        "Hello from Person"
    }
}

class Employee: Person {
    override func greet() -> String {
        "Hello from Employee"
    }
}

let p: Greetable = Person()
let e: Greetable = Employee()
print(p.greet())
print(e.greet())

medium

A. Hello from Person
Hello from Employee

B. Hello from Person
Hello from Person

C. Hello from Employee
Hello from Employee

D. Compilation error due to protocol conformance

Solution

1. Step 1: Understand protocol conformance and inheritance

   Person conforms to Greetable with greet() returning "Hello from Person". Employee inherits Person and overrides greet() to return "Hello from Employee".

2. Step 2: Analyze output of print statements

   Variable p is Person instance, so p.greet() returns "Hello from Person". Variable e is Employee instance, so e.greet() returns "Hello from Employee".

3. Final Answer:

   Hello from Person Hello from Employee -> Option A

4. Quick Check:

   Inheritance override works, prints Person then Employee [OK]

Hint: Subclass overrides method; output reflects actual instance type [OK]

Common Mistakes:

• Assuming protocol type erases override
• Confusing struct and class inheritance
• Expecting compilation error for override

4. Identify the error in this Swift code that tries to use POP and OOP together:

protocol Drawable {
    func draw()
}

class Shape: Drawable {
    func draw() {
        print("Drawing shape")
    }
}

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

medium

A. Circle struct must use 'override' keyword for draw().

B. Protocol Drawable is missing required methods.

C. Class Shape cannot conform to protocol Drawable.

D. Struct cannot inherit from a class; Circle cannot inherit from Shape.

Solution

1. Step 1: Check inheritance rules for structs and classes

   In Swift, structs cannot inherit from classes. Circle is a struct trying to inherit from class Shape, which is invalid.

2. Step 2: Verify protocol conformance and method implementation

   Shape correctly conforms to Drawable. Circle tries to override draw(), but inheritance is invalid for structs.

3. Final Answer:

   Struct cannot inherit from a class; Circle cannot inherit from Shape. -> Option D

4. Quick Check:

   Structs cannot inherit classes in Swift [OK]

Hint: Structs cannot inherit classes; use protocols for shared behavior [OK]

Common Mistakes:

• Thinking structs can inherit classes
• Confusing protocol conformance with inheritance
• Using 'override' in struct methods

5. You want to design a Swift app where multiple types share behavior but also have unique data. You want flexibility to add new behaviors without deep inheritance chains. Which approach fits best?

hard

A. Use deep class inheritance with base classes and subclasses for all types.

B. Use Protocol-Oriented Programming with protocols and structs to share behavior and data.

C. Use only classes without protocols to simplify code.

D. Use global functions instead of protocols or classes.

Solution

1. Step 1: Analyze design goals

   The goal is to share behavior, have unique data, and avoid deep inheritance chains for flexibility.

2. Step 2: Match goals to programming paradigms

   POP uses protocols and structs to share behavior flexibly without inheritance. OOP with deep inheritance is less flexible and can be complex.

3. Final Answer:

   Use Protocol-Oriented Programming with protocols and structs to share behavior and data. -> Option B

4. Quick Check:

   Flexible behavior sharing = POP with protocols & structs [OK]

Hint: For flexible shared behavior, prefer POP with protocols and structs [OK]

Common Mistakes:

• Choosing deep inheritance causing rigid design
• Ignoring protocols for behavior sharing
• Using global functions losing type safety