Why Swift is a protocol-oriented language

You’ve learned about the capabilities of protocols and protocol extensions, but you may be wondering: What exactly does it mean that Swift is a protocol-oriented language?

Protocol extensions greatly affect your ability to write expressive and decoupled code — and many of the design patterns that protocol extensions enable are reflected in the Swift language itself.

To begin, you can contrast protocol-oriented programming with object-oriented programming. The latter is focused on the idea of objects and how they interact. Because of this, the class is at the center of any object-oriented language.

Though classes are a part of Swift, you’ll find they are an extremely small part of the standard library. Instead, Swift is built primarily on a collection of structs and protocols. At the time of writing, for example, the Swift core library breaks down classes, enums, structs, and protocols like this:

• Class: 3
• Enum: 17
• Struct: 114
• Protocol: 95

You can see the significance of this in many of Swift’s core types, such as Int and

Array. Consider the definition of Array:

// From the Swift standard library

public struct Array<Element> : RandomAccessCollection, MutableCollection

{

// ...

}

The fact that Array is a struct means it’s a value type, of course, but it also means that it can’t be subclassed and it can’t be a superclass. Instead of inheriting behaviors from common base classes, Array adopts protocols to define many of its more common capabilities.

In addition to the definition, Array has 16 extensions. 10 of those extensions declare conformance to another protocol, and 5 of those have generic constraints.

Array is a MutableCollection, which is also a Collection. Thanks to protocol extensions, Array will get numerous properties and methods common to all Collections such as first, count, or isEmpty — simply by being a Collection. Thanks to many protocol extensions with generic constraints, you can split() an Array or find the index(of:) an element — if the type of that element conforms to Equatable.

These implementations are all defined within protocol extensions in the Swift standard library. By implementing them in protocol extensions, these behaviors can be treated as mix-ins, and do not need to be explicitly reimplemented on each adopting type.

This decoration of defined behaviors lets Array and Dictionary — yet another Collection — be similar in some respects and different in others. Had Swift used subclassing, Dictionary and Array would either share one common base class or none at all. With protocols and protocol-oriented programming, you can treat them both as a Collection.

With a design centered around protocols rather than specific classes, structs or enums, your code is instantly more portable and decoupled, because methods now apply to a range of types instead of one specific type. Your code is also more cohesive, because it operates only on the properties and methods within the protocol you’re extending and its type constraints, and ignores the internal details of any type that conforms to it.

Understanding protocol-oriented programming is a powerful skill that will help you become a better Swift developer, and give you new ways to think about how to design your code.

Note: More neutral-minded Swift developers will call Swift a “multi-paradigm” language. You’ve already seen inheritance and object-oriented techniques, and

now protocol-oriented programming; Swift easily handles both!