Protocol types in Swift.

Tram Ho

  • The main role of the protocol / interface is to allow common abstraction to be defined on specific implementations. A technique called polymorphism allows us to swap / morph implementations without affecting the public API.
  • Although Swift has full support for interface based polymorphism protocol still play a large role in the overall design of language and lib as part of the main functionality that Swift implements directly above other protocols.
  • protocol-oriented design allows us to use protocol in a variety of ways in source code . Let’s take a look at those ways and let’s see how Apple uses their protocol .

1 / Enabling unified actions:

  • Start by looking at protocol require the right type to be able to perform specific action . For example, the protocol Equatable is used to mark that a type can perform equality checks between two cases, while the protocol Hashable accepted by type can be hashed :

  • The great benefit of these two capabilities being specified by using the system (instead of being encoded into the compiler) is that it allows us to write generic code bound to protocol that allows us to use make full use of the capabilities in that code .
  • The way we can extend Array with a method helps us count all occurrences of a value provided that the type of Element array matches Equatable :

  • Whenever defined protocol based on the action we should make the protocol that generic as possible (like Equitable and Hashable ) as we remain focused on the action instead of binding with name domain -specific .
  • For example, if we want to unify different types of loading objects or values, we can define a downloadable protocol with a related type – which will allow each type to comply with the result type declaration. which it loads:

However, not all protocol define action . While the name of the protocol :

  • Comparing the protocol Codable and Cachable protocol Codable we define actions for both encode and decode .
  • Not all protocol need to use suffix . Binding suffix to any particular noun just to define the protocol can lead to a lot of confusion:

  • Even more confusing is that using suffix can create a name with a completely different meaning. For example, we have defined a protocol that aims to act as an API for color container but the name suggests that it can be colored for type that can be colored by themselves:

  • We can improve some of these protocol both in naming and in how they are structured. By stepping out of section one and looking at a few different ways to define protocol in Swift .

2 / Defining requirements:

  • Item number two is for protocol used to define formal requirements for a certain type of object or API . In the standard library , protocol are used to determine the meaning of Collection , Numberic or Sequence :

  • The above definition of Sequence tells us that the main role of any Swift sequence (such as Array , Dictionary or Range ) acts as a factory to create loops to be formalized through the following protocol :

  • For those two protocol let’s go back to the saved and protocol we defined earlier, to see if they can be improved by converting them into the required definitions instead. So.

  • Similarly, we can rename Cachabl to:

  • Let’s move our key generation code into separate types – then we can formalize the requirements to use the protocol CacheKeyGenerator :

3 / Type conversions:

  • Let’s look at the protocol used to declare that one type can be converted to and from other value . Let’s start again with an example from the standard library , the CustomStringConvertible is used to allow any type to be converted into a description string :

  • That type of writing is especially useful when we can extract a portion of the dât from multiple type perfectly fit the purpose of the Titleable protocol .
  • By renaming the protocol to TitleConvertible they not only make it easier to understand, but also make our code more suitable to the standard library :

  • type conversion protocol can also use method instead of property . This is usually more appropriate when we want to implement reasonable computational requirements:

  • We can also use this type of protocol to allow certain type in different ways:

  • For example: How we can define the protocol ExpressibleByUUID for identifier types can be created by UUID :

4 / Abstract interfaces:

  • Finally, let’s take a look at perhaps the most common protocol used in third-party code to define abstract to communicate with many basic type .
  • An example that can be found in the Apple Metal framework is the low level graphical programming API . Because the GPU varies a lot between devices and Metal aims to provide an API suits every hardware it supports, it uses a protocol to determine the API :

  • When using Metal we can call the MTLCreateSystemDefaultDevice function and the system will return the implementation of the protocol appropriate to the device that our code is currently running:

  • For example, we can define the NetworkEngine protocol to separate the way we make network call from any network medium:

  • We can now freely define the number of basic network deployments we need – for example, an application based on URLSession to produce and a mock version for testing:

Share the news now

Source : Viblo