POP vs OOP decision patterns in Swift - Trade-offs & Expert Analysis

Overview - POP vs OOP decision patterns

What is it?

POP (Protocol-Oriented Programming) and OOP (Object-Oriented Programming) are two ways to organize code. OOP uses classes and inheritance to model real-world things with properties and behaviors. POP uses protocols to define blueprints of methods and properties, focusing on what things can do rather than what they are. Both help write reusable and clear code but approach problems differently.

Why it matters

Choosing between POP and OOP affects how easy your code is to change, test, and grow. Without understanding these patterns, code can become tangled, hard to fix, or extend. Using the right pattern makes your app more reliable and easier to build new features, saving time and frustration.

Where it fits

Before this, you should know basic Swift syntax, functions, and simple data types. After learning this, you can explore advanced Swift features like generics, protocol extensions, and design patterns like MVVM or dependency injection.

Mental Model

Core Idea

POP focuses on defining behaviors through protocols that types conform to, while OOP organizes code by creating class hierarchies that share properties and methods through inheritance.

Think of it like...

Think of OOP like a family tree where children inherit traits from parents, while POP is like a team where everyone agrees on roles and responsibilities regardless of their background.

┌─────────────┐          ┌─────────────┐
│   OOP       │          │    POP      │
├─────────────┤          ├─────────────┤
│ Class       │          │ Protocol    │
│ Inheritance │◄─────────│ Conformance │
│ Properties  │          │ Behavior    │
│ Methods     │          │ Definitions │
└─────────────┘          └─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Classes and Objects

Concept: Introduce classes as blueprints for creating objects with properties and methods.

In Swift, a class defines a type with properties and functions. You create objects (instances) from classes. For example: class Car { var color: String init(color: String) { self.color = color } func drive() { print("Driving a \(color) car") } } let myCar = Car(color: "red") myCar.drive()

Result

Driving a red car

Understanding classes and objects is the base of OOP, showing how data and behavior are bundled together.

2

Foundation

Introducing Protocols and Conformance

Concept: Explain protocols as blueprints for methods and properties that types can adopt.

A protocol defines what methods or properties a type must have, without providing the implementation. For example: protocol Drivable { func drive() } struct Bike: Drivable { func drive() { print("Riding the bike") } } let myBike = Bike() myBike.drive()

Result

Riding the bike

Protocols let different types promise to provide certain behaviors, enabling flexible and reusable code.

3

Intermediate

Comparing Inheritance and Protocol Conformance

🤔Before reading on: Do you think inheritance allows sharing behavior only from one parent or multiple parents? Commit to your answer.

Concept: Show how OOP uses single inheritance to share behavior, while POP uses protocols to share behavior across many types.

In OOP, a class can inherit from only one parent class: class Vehicle { func start() { print("Starting vehicle") } } class Car: Vehicle { func drive() { print("Driving car") } } Car inherits start() from Vehicle. In POP, a type can conform to many protocols: protocol Startable { func start() } protocol Drivable { func drive() } struct Scooter: Startable, Drivable { func start() { print("Starting scooter") } func drive() { print("Driving scooter") } }

Result

Scooter can start and drive by conforming to two protocols, while Car inherits start() from Vehicle.

Knowing that protocols allow multiple behavior sharing avoids the rigid single inheritance limit in OOP.

4

Intermediate

Using Protocol Extensions for Default Behavior

🤔Before reading on: Do you think protocols can provide default method implementations? Commit to your answer.

Concept: Protocols can have extensions that provide default method implementations, reducing code duplication.

You can add default behavior to protocols: protocol Drivable { func drive() } extension Drivable { func drive() { print("Default driving") } } struct Skateboard: Drivable {} let board = Skateboard() board.drive()

Result

Default driving

Understanding protocol extensions lets you write flexible code that shares behavior without inheritance.

5

Intermediate

Deciding When to Use POP or OOP

🤔Before reading on: Do you think POP is better for shared behavior or shared identity? Commit to your answer.

Concept: Explain that OOP is good for modeling objects with identity and state, while POP is better for shared behavior and flexibility.

Use OOP when you need: - Objects with unique identity - Shared state and inheritance Use POP when you want: - Flexible behavior sharing - Composition over inheritance - Easier testing and mocking Example: A game character with unique state fits OOP; a set of abilities shared by many types fits POP.

Result

Clear guidelines help choose the right pattern for your problem.

Knowing the strengths of each pattern helps avoid overcomplicated or rigid designs.

6

Advanced

Combining POP and OOP in Swift

🤔Before reading on: Can classes conform to protocols and use protocol extensions? Commit to your answer.

Concept: Show how Swift allows mixing OOP and POP by having classes conform to protocols and benefit from protocol extensions.

Classes can adopt protocols: protocol Flyable { func fly() } extension Flyable { func fly() { print("Flying") } } class Bird: Flyable { // Uses default fly() } let sparrow = Bird() sparrow.fly()

Result

Flying

Understanding this mix lets you design flexible, reusable code that leverages both paradigms.

7

Expert

Avoiding Common Pitfalls in POP vs OOP

🤔Before reading on: Do you think using inheritance everywhere is always better than protocols? Commit to your answer.

Concept: Highlight subtle issues like tight coupling in OOP inheritance and protocol complexity in POP, and how to balance them.

Overusing inheritance can make code fragile and hard to change. Protocols can become complex if too many are combined. Best practice: - Use protocols for behavior abstraction - Use inheritance sparingly for shared state - Prefer composition over inheritance Example: Instead of a deep class hierarchy, use protocols and extensions to compose behavior.

Result

More maintainable and adaptable codebases.

Knowing these trade-offs prevents common design mistakes that cause bugs and slow development.

Under the Hood

Swift compiles classes and protocols differently. Classes support inheritance with a vtable for method dispatch, allowing dynamic method calls. Protocols use witness tables to map protocol requirements to concrete implementations, enabling static or dynamic dispatch. Protocol extensions provide default implementations that types can override. This design allows flexible code reuse and efficient execution.

Why designed this way?

Swift was designed to combine the power of OOP with the flexibility of POP to overcome limitations of single inheritance and improve code reuse. Protocols and extensions enable composition, which is more modular and testable. This approach was chosen to modernize Swift and encourage safer, clearer code compared to traditional OOP-heavy languages.

┌───────────────┐       ┌───────────────┐
│   Class       │       │   Protocol    │
│  (OOP)       │       │   (POP)       │
├───────────────┤       ├───────────────┤
│ Inheritance   │       │ Conformance   │
│ Vtable       │◄──────│ Witness Table │
│ Dynamic Dispatch│     │ Default Impl  │
└───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think protocols can hold stored properties like classes? Commit to yes or no.

Common Belief: Protocols can have stored properties just like classes.

Reality: Protocols cannot have stored properties; they only define method and property requirements without storage.

Why it matters: Trying to store data in protocols leads to compiler errors and confusion about where data lives.

Quick: Do you think inheritance allows a class to inherit from multiple parents? Commit to yes or no.

Common Belief: Classes can inherit from multiple parent classes to combine behaviors.

Reality: Swift classes support only single inheritance; multiple inheritance is not allowed.

Why it matters: Assuming multiple inheritance leads to design errors and misuse of protocols for behavior sharing.

Quick: Do you think protocol extensions always override class methods? Commit to yes or no.

Common Belief: Protocol extension methods override class methods if both exist.

Reality: Class methods always take precedence over protocol extension methods; extensions provide defaults only if class doesn't implement them.

Why it matters: Misunderstanding this causes unexpected behavior and bugs in method dispatch.

Quick: Do you think POP is always better than OOP? Commit to yes or no.

Common Belief: POP is the modern way and should replace OOP everywhere.

Reality: Both have strengths; OOP is better for modeling identity and state, POP for flexible behavior sharing.

Why it matters: Ignoring OOP leads to awkward designs when identity or shared state is important.

Expert Zone

1

Protocol composition allows combining multiple protocols to express complex behavior without inheritance.

2

Using 'where' clauses in protocol extensions enables conditional default implementations based on conforming types.

3

Classes conforming to protocols can leverage dynamic dispatch, while structs use static dispatch, affecting performance and flexibility.

When NOT to use

Avoid using deep class inheritance hierarchies as they cause tight coupling and fragile code. Instead, use protocol composition and struct types for flexibility. Conversely, avoid using POP when you need shared mutable state or identity, where OOP classes are more suitable.

Production Patterns

In real apps, developers use POP for defining capabilities like 'Drivable' or 'Serializable' and compose them on structs for safety and testability. OOP is used for UI components or models with identity. Combining both, protocols define interfaces, and classes provide concrete implementations, enabling clean architecture and easier maintenance.

Connections

Functional Programming

POP shares the idea of composing behavior from small, reusable pieces, similar to functions in FP.

Understanding POP helps grasp how to build programs by combining simple behaviors, a core idea in functional programming.

Design Patterns

Both POP and OOP are foundations for design patterns like Strategy, Adapter, and Decorator.

Knowing POP and OOP clarifies how design patterns solve common problems by organizing code structure and behavior.

Team Sports

Like POP protocols define roles players must perform, team sports assign roles to players regardless of their background.

This connection shows how focusing on roles (behaviors) rather than lineage (inheritance) leads to flexible and effective teams.

Common Pitfalls

#1 Trying to store data directly in protocols.

Wrong approach:

protocol Vehicle {
var speed: Int = 0
}

Correct approach:

protocol Vehicle {
var speed: Int { get set }
}

Root cause:

Misunderstanding that protocols define requirements but cannot hold stored data.

#2 Using deep class inheritance for code reuse.

Wrong approach:

class Animal {}
class Dog: Animal {}
class Puppy: Dog {}

Correct approach:

protocol Barkable { func bark() }
struct Puppy: Barkable { func bark() { print("Woof") } }

Root cause:

Believing inheritance is the only way to share behavior, ignoring protocol composition.

#3 Expecting protocol extension methods to override class methods.

Wrong approach:

protocol Flyable { func fly() }
extension Flyable { func fly() { print("Flying") } }
class Bird: Flyable { func fly() { print("Bird flying") } }

Correct approach:

class Bird: Flyable { func fly() { print("Bird flying") } }

Root cause:

Not realizing class methods always override protocol extension defaults.

Key Takeaways

POP and OOP are two complementary ways to organize code: POP focuses on behavior through protocols, OOP on identity through classes.

Protocols define what a type can do, not what it is, enabling flexible and reusable code without inheritance limits.

Classes support inheritance and shared state but can lead to rigid designs if overused.

Swift allows mixing POP and OOP, letting you choose the best tool for each problem.

Understanding when and how to use POP and OOP prevents common design mistakes and leads to cleaner, maintainable code.