Chathura
17 September 2024
Naming your Protocols
This is the part 2 of the Swift Protocol Oriented Programming series, the first part was an introduction to Protocols compared to Java Interfaces and some of the basic characteristics of both compared in one-to-one manner. However as a developer, the more important questions are asked when and how we can use POP design pattern in our day to day coding. Let's dig in to it a bit.
The naming of a class
I know few developers who still want to name their programming components with the breakfast they had that day, but it is high time we have to understand how naming of your programming components affects the readability of the code you write. I always used to think that a program is like a script for a documentary show. It is not fictional, hence it is not a novel or a short story but there is a story to tell, not just to the compiler and the program controller but the developers who read and maintains that code in years to come. If you make the story readable and understandable, it makes their lives easier.
Likewise, naming of protocols is important as any other variable or class name in your Swift code, how so, lets take a look at couple of examples for the sake of our understanding. I have over a decade of experience in the Fintech industry, including the biggest players in the world today, hence let me use an example from a real world use case.
Lets think of a name for a class which can be used to process a credit card, and it could contain few basic properties such as,
- cardInfo - A attribute of type CreditCard which is a domain model with all the credit card info.
- bankInfo - Reference to another class which holds the BankingInformation
issuer - Another reference to the Issuer such as Visa or Amex
Simple as that it should be. And if we go further into behaviors, the following methods could add some more color to it.
- validateCardInformation - A simple validation logic to validate the card information
- processCard - The core business logic to process the card info along with banking and issuer properties by submitting to a backend gateway.
- handleResponse - Method which handles the response for processing the card.
What was the name you came across ? Of course it shouldn't be that difficult to think of, if you came up with a verb such as CreditCardProcessor, I think we are on the same page.
The name CreditCardProcessor suites very well as it represents both the properties and behaviors this real world entity is all about.
...and the Protocol Name is
Now, lets take a step back and think if we are going to make this more generic so that other modules can implement the same class in a different way, the answer is always Protocols in Swift. What should be your naming suggestion for this particular class in that regards ?
If you come up with a name such as CreditCardProcessorManager or CreditCardProcessorCoordinator or even CreditCardProcessorInterface, I wouldn't say you are wrong. But the reality is that it doesn't accurately represents what this Protocol is asking its implementers to do. So then, whats the best answer, well there is no best answer but I can giver a better answer.
My answer to that question is by simply making the verb a present participle , yes, just add ing to the end and you have it ! In this case, it will be CreditCardProcessing and simple as that. It will work for the most scenarios, but there will be certains cases which it wouldn't work. Please comment and share with me of such use cases, and I'm happy to reply.
I will come up with a third part to the protocol oriented programming in a future article. However, I'm thinking of moving to a new topic until I'm done preparing the next POP article. Please keep in touch and keep coding.
Add new comment