What is protocol-oriented programming, and when does it fail?

1.3.2 · L2 · Interview

Mental model. POP is composition over inheritance — assemble behaviour from small protocols instead of building a family tree.

Model behaviour as small protocols plus extensions plus generics, instead of a deep class hierarchy. You get composition, retroactive conformance (conforming a type you do not own), and value-type support.

It fails when you need genuine runtime identity, Objective-C interop, or when associated types make the protocol unusable as any P and you end up writing a type eraser per protocol. At that point, a base class or a concrete enum is often simpler and faster.

Common traps

  • Turning every concept into a protocol. A protocol with one conformer is an abstraction with no payoff — and it costs dispatch and readability.
  • Ignoring the PAT tax. A protocol with associatedtype cannot be stored as a plain existential without constraints or erasure.

They might follow up with

  • When is a class hierarchy better? Shared stored state plus template-method behaviour, or when you need ObjC runtime features.
  • What is retroactive conformance? Extending a type you do not own to conform to a protocol you do own. Handy, but it can cause duplicate-conformance conflicts across modules.

Related questions

  • 1.3.1 What can live in a protocol? What can live in an extension?
  • 1.3.5 What is an associated type? Why can’t you write let x: MyPAT easily?
  • 1.3.7 What is a type eraser (AnyHashable, AnyView, AnyCancellable)? When do you write one?

← What can live in a protocol? What can live in an extension?   Protocol extension vs inheritance for default behaviour — what are… →