Naming a Protocol in Swift

What’s In A Name?

I am a big fanatic of Protocol Oriented Programming (POP). Hope every one of us might have read about it. Or never the less a bit fancier of the protocol-oriented design during design and implementation.

You all might have read many articles around, How to use protocols? What is POP? i.e., hiding, abstraction, loose coupling, segregation, testability, etc.

Hopefully, everyone of us might have used one of the below protocol now and then,

• Hashable
• Codable
• Encodable
• Decodable
• Equatable

Have we thought of why these names?

giphy.com

All these protocols names are suffix with ‘able’.

So, Should we append ‘able’ to every protocol we are writing?

Wait…

There are a few other protocols like Iterator, UITableViewDelegate, Collection, Sequence, and many more.

We are the consumer of these protocols. At first glance, it feels not like a big deal.

Why you need this article?

Wear the implementers shoe.

Gabriel Jürgensen

Your brain on🔥🔥🔥

You want to provide a protocol that will be consumed by other implementer. And consumer to feel the way we are feeling for inbuilt protocol.

Step 0 — What should be the name?

So, Should we append ‘able’ to every protocol we are writing?

We are not sure right now.

Have we thought of it? If yes, what is our understanding and prospective? If no, why?

We might not be paid lots of attention to reading about it, or not seen any article on it. There might be a couple of articles or blogs, but we might have ignored them, or they might not have come to our notice.

In this article, I will give my perspective and philosophy of deciding the names for the protocol, that some might agree, some might not. That’s fine.

Let’s go through the complete article. It will help us to understand the perspective and hopefully answer our questions.

Let us go back to the basics and try and understand what the swift book says about the protocol.

“A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality. The protocol can then be adopted by a class, structure, or enumeration to provide an actual implementation of those requirements. Any type that satisfies the requirements of a protocol is said to conform to that protocol.”

Reference: Swift Language

In simple words, Interface [I know, protocol are more powerful.].

Protocol is to provide blueprint to classes, structs, and enums to work upon.

High-Level Purpose Of having protocol, Abstraction, Loose Coupling, For Delegation, Segregation and Testability, etc.

We should choose self explanatory names for protocol. Which help to understand the high-level purpose as mentioned above.

🫳 Have a protocol which all the implementer/conformer to perform a declared action in the protocol on themselves,for me they are actionable.

able

We can say instance of animal is an equatable object.

🫳 Protocol, that allows the implementer/conformer for doing work as requested and respond.

ing

We can say instance of the network allow a networking feature.

🫳 Protocol as interface for testability with maximum coverage by mocking. They are more like designer dresses. Means a single blueprint as per the demand of the implementer.

This is not fitting to our previous criteria? What should be the name for it?

Let’s use RandomNumberGenerator. What should be the implementer/conformer name? RandomNumberGenerator?

NOTE: We cannot have the same name for protocol and the implementer/conformer. Compiler error as compiler will see two declarations with the same name.

Giving name to the concrete implementer/conformer is little difficult here. Isn’t it?

Should we use different naming conventions for protocol?

I think, User generic name to a protocol called NumberGenerator.

Name only

Name only

Sounds good. But will this strategy work every time?

Let’s see and every day problem…

Mostly, we use MVVM architecture. We will have couple of ViewModels like, LoginViewModel, CartViewModel, WishlistViewModel, etc.

We follow POP. What will be suitable protocol names for it? The above mentioned strategy will fail and having different conditional naming strategies will not work.

I think it’s easy, convenient, and yet more declarative, LoginViewModelProtocol, CartViewModelProtocol, etc.

name+Protocol

We can have a name+Protocol naming conventions suits for this requirement.

🫳 Protocol is also used for hand off (or delegate) some of its responsibilities to an instance of another type i.e., delegating responsibilities (Delegation Design Pattern).

o To indicate what the protocol is meant for.

Example: ScoreDelegate, ResponseDelegate, etc.

name+delegate

Single source of truth: Swift API Design Guidelines

• Protocols that describe what something is should read as nouns (e.g. Collection).
• Protocols that describe a capability should be named using the suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

Guideline to choose appropriate name, ask your self a question and answer will be one of below,

Performed by = name+ing

Performed on = name+able

Performed for = name+delegate

Unable to identify = name + protocol

“Clear suffixes are a better idea for decode the purpose of the noun.”

Do clap if you like the article!!!