Protocol-Oriented Programming and Cocoa (Part 1)

[[403413]]

This article is reprinted from the WeChat public account "Swift Community", written by Onevcat. Please contact the Swift Community public account to reprint this article.

This article is a summary of the author's keynote speech at the iOS session at MDCC 16 (Mobile Developer Conference). Published on November 29, 2016 and last updated on October 22, 2020

You can find the keynote used in the speech here [1], and some sample code can be found in the official repo of MDCC 2016 [2]. Because the entire content is quite long, it is divided into two parts. This article (Part 1) mainly introduces some theoretical content, including the problems existing in object-oriented programming, the basic concepts and decision-making models of protocol-oriented programming, etc. The second part mainly shows some sample codes that the author uses in daily life to combine protocol-oriented thinking with Cocoa development, and explains them.

1. Introduction

Protocol Oriented Programming (POP) is a programming paradigm for Swift proposed by Apple at WWDC in 2015. Compared with traditional object-oriented programming (OOP), POP is more flexible. Combined with Swift's value semantics and the implementation of the Swift standard library, many application scenarios of POP have been discovered in the past year.

This speech hopes to introduce some scenarios where POP can be used in daily development based on the introduction of POP ideas, so that the guests can start to try POP in their daily work and improve code design.

2. What is Swift Protocol

2.1 Protocol

There are more than 50 protocols of varying complexity in the Swift standard library, and almost all actual types satisfy several protocols. Protocol is the foundation of the Swift language, and the rest of the language is organized and built on this foundation. This is very different from the object-oriented construction method we are familiar with.

A simple but useful Swift protocol definition is as follows:

 protocol Greetable {
 var name : String { get }
 func greet()
 }

These lines of code define a protocol called Greetable, which has a name property and a greet method.

A protocol is a set of properties and/or methods, and if a specific type wants to comply with a protocol, it needs to implement all of the contents defined by the protocol. What a protocol actually does is nothing more than "agreement on implementation."

2.2 Object-Oriented

Before we delve into the concept of Swift protocols, I would like to review object-orientation. I believe we are all very familiar with this term in textbooks, blogs, and other places. Then there is a very interesting question, but not every programmer has thought about it. What is the core idea of ​​object-orientation?

Let's first look at a piece of object-oriented code:

 class Animal {
 var leg: Int { return 2 }
 func eat() {
 print( "eat food." )
 }
 func run() {
        print( "run with \(leg) legs" )
 }
 } 
 
 class Tiger: Animal {
    override var leg: Int { return 4 }
 override func eat() {
 print( "eat meat." )
 }
 } 
 
 let tiger = Tiger()
 tiger.eat() // "eat meat"  
 tiger.run() // "run with 4 legs"  

The parent class Animal defines the animal's leg (a virtual class should be used here, but there is no such concept in Swift, so please ignore return 2 here), as well as the animal's eat and run methods, and provides implementations for them. The subclass Tiger rewrites leg (4 legs) and eat (eat meat) according to its own situation, and for run, the parent class's implementation already meets the requirements, so there is no need to rewrite it.

We can see that Tiger and Animal share some code, which is encapsulated in the parent class, and other subclasses except Tiger can also use this code of Animal. This is actually the core idea of ​​OOP - using encapsulation and inheritance to put a series of related contents together.

Our predecessors developed the concept of object-oriented programming in order to model real-world objects, but this concept has some flaws. Although we try to model with this set of abstraction and inheritance methods, real things are often a combination of a series of characteristics, rather than simply being built in a consistent and gradually expanded way.

So recently, more and more people have discovered that object-oriented programming often cannot abstract things very well, and we may need to find another better way.

2.3 Dilemma of Object-Oriented Programming

2.3.1 Cross-cutting concerns

Let's look at another example. This time let's stay away from the animal world and return to Cocoa. Suppose we have a ViewController that inherits from UIViewController, and we add a myMethod to it:

 class ViewController: UIViewController
 {
 // Inheritance
    // view , isFirstResponder()... 
     
 // New
 func myMethod() { 
         
 }
 }

If we have another ViewController that inherits from UITableViewController, we also want to add the same myMethod to it:

 class AnotherViewController: UITableViewController
 {
 // Inheritance
    // tableView, isFirstResponder()... 
     
 // New
 func myMethod() { 
         
 }
 }

At this point, we have encountered the first major dilemma of OOP, that is, it is difficult for us to share code between classes with different inheritance relationships. The problem here is called "cross-cutting concerns" in "jargon". Our concern myMethod is located at the cross-section of two inheritance chains (UIViewController -> ViewCotroller and UIViewController -> UITableViewController -> AnotherViewController).

Object-oriented is a good way of abstraction, but it is definitely not the best way. It cannot describe the fact that two different things have the same characteristics. Here, the combination of characteristics is more in line with the essence of things than inheritance.

To solve this problem, we have several solutions:

• Copy & Paste

This is a bad solution, but many people still chose this solution at the presentation, especially when the deadline is tight and there is no time for optimization. This is understandable, but it is also the beginning of bad code. We should try to avoid this practice.

• Introducing BaseViewController

Add the code you need to share to a BaseViewController that inherits from UIViewController, or simply add an extension to UIViewController. This seems to be a slightly more reliable approach, but if you keep doing this, the so-called Base will quickly become a garbage dump. Without clear responsibilities, anything can be thrown into the Base, and you have no idea which classes have left the Base, and the impact of this "super class" on the code will also be unpredictable.

• Dependency Injection

By passing an object with myMethod from the outside world, and using a new type to provide this function, this is a slightly better way, but it introduces additional dependencies, which we may not want to see.

• Multiple inheritance

Of course, Swift does not support multiple inheritance. But if there is multiple inheritance, we can indeed inherit from multiple parent classes and add myMethod to the appropriate place. Some languages ​​choose to support multiple inheritance (such as C++), but it will bring another famous problem in OOP: the diamond defect.

2.3.2 Diamond defect

In the example above, if we have multiple inheritance, the relationship between ViewController and AnotherViewController might be like this:

Pictures here

In the above topology, we only need to implement myMethod in ViewController, and then inherit and use it in AnotherViewController. It looks perfect, and we avoid duplication.

However, there is an unavoidable problem with multiple inheritance, which is when two parent classes implement the same method, what should the child class do? It is difficult for us to determine which parent class method should be inherited. Because the topological structure of multiple inheritance is a diamond, this problem is also called the diamond problem.

Languages ​​like C++ choose to rudely leave the problem of the diamond defect to the programmer, which is undoubtedly very complicated and increases the possibility of human error. Most modern languages ​​choose to stay away from the feature of multiple inheritance.

2.3.3 Dynamic dispatch security

Objective-C is a typical OOP language, just as its name suggests. It also inherits the message sending mechanism of Small Talk. This mechanism is very flexible and is the basic idea of ​​OC, but it is sometimes relatively dangerous. Consider the following code:

 ViewController *v1 = ...
 [v1 myMethod]; 
 
 AnotherViewController *v2 = ...
 [v2 myMethod]; 
 
 NSArray *array = @[v1, v2];
 for (id obj in array) {
 [obj myMethod];
 }

If we implement myMethod in both ViewController and AnotherViewController, this code is fine. myMethod will be dynamically sent to v1 and v2 in the array. However, what if we have a type that does not implement myMethod?

 NSObject *v3 = [NSObject new]
 // v3 does not implement `myMethod` 
 
 NSArray *array = @[v1, v2, v3];
 for (id obj in array) {
 [obj myMethod];
 } 
 
 // Runtime error:
 // unrecognized selector sent to instance blabla

The compilation will still pass, but obviously, the program will crash at runtime. Objective-C is unsafe, and the compiler assumes that you know that a method is actually implemented. This is the price you must pay for the flexibility of message sending.

From the perspective of app development, the price of flexibility in exchange for possible crashes is obviously too high. Although this is not a problem of the OOP paradigm, it did bring us pain in the Objective-C era.

2.3.4 Three major dilemmas

We can summarize the problems faced by OOP:

• Dynamic dispatch security
• Cross-cutting concerns
• Diamond defect

First, dynamic dispatch in OC puts us at risk of discovering errors at runtime, which is likely to be an error in the online product. Second, cross-cutting concerns make it difficult for us to model objects perfectly, and code reuse will be even worse.

3. Protocol extension and protocol-oriented programming

3.1 Using protocols to solve OOP dilemmas

Protocols are not new, nor are they invented by Swift. In Java and C#, they are called Interfaces. Protocols in Swift inherit this concept and carry it forward. Let's go back to the simple protocol we defined at the beginning and try to implement it:

 protocol Greetable {
 var name : String { get }
 func greet()
 }

 struct Person: Greetable {
 let name : String
 func greet() {
 print( "Hello \(name)" )
 }
 }
 Person( name : "Wei Wang" ).greet()

The implementation is simple, the Person structure satisfies Greetable by implementing name and greet. When calling, we can use the methods defined in Greetable.

3.1.1 Dynamic dispatch security

In addition to Person, other types can also implement Greetable, such as Cat:

 struct Cat: Greetable {
 let name : String
 func greet() {
        print( "meow~ \(name)" )
 }
 }

Now, we can use the protocol as a standard type to dynamically dispatch method calls:

 let array: [Greetable] = [
  Person( name : "Wei Wang" ),
 Cat( name : "onevcat" )]
 for obj in array {
 obj.greet()
 }
 // Hello Wei Wang
 // meow~ onevcat

For types that do not implement Greetbale, the compiler will return an error, so there is no possibility of mis-sending messages:

 struct Bug: Greetable {
 let name : String
 } 
 
 // Compiler Error:
 // 'Bug' does not conform to protocol 'Greetable'  
 // protocol requires function   'greet()'  

This way, the issue of dynamic dispatch safety is solved. If you stay in the Swift world, all your code is safe.

• Dynamic dispatch security
• Cross-cutting concerns
• Diamond defect

3.1.2 Cross-cutting concerns

Using protocols and protocol extensions, we can share code very well. Going back to the myMethod method in the previous section, let's see how to use protocols to handle it. First, we can define a protocol containing myMethod:

 protocol P
 func myMethod()
 }

Note that this protocol does not provide any implementation. We still need to provide a concrete implementation for it when the actual type conforms to this protocol:

 // class ViewController: UIViewController
 extension ViewController: P {
 func myMethod() {
 doWork()
 }
 } 
 
 // class AnotherViewController: UITableViewController
 extension AnotherViewController: P {
 func myMethod() {
 doWork()
 }
 }

You may ask, how is this different from the Copy & Paste solution? Well, the answer is – no difference. But don't worry, we have other technologies to solve this problem, that is, protocol extension. The protocol itself is not very powerful, it is just a compiler guarantee for statically typed languages, and there are similar concepts in many static languages.

So what makes Swift a protocol-first language? The real reason why protocols have undergone a qualitative change and attracted so much attention is that when WWDC 2015 and Swift 2 were released, Apple introduced a new feature for protocols, protocol extensions, which brought a revolutionary change to the Swift language.

The so-called protocol extension means that we can provide a default implementation for a protocol. For P, we can add an implementation for myMethod in extension P:

 protocol P
 func myMethod()
 } 
 
 extension P {
 func myMethod() {
 doWork()
 }
 }

With this protocol extension, we simply need to declare that ViewController and AnotherViewController comply with P, and then we can directly use the implementation of myMethod:

 extension ViewController: P { }
 extension AnotherViewController: P { } 
 
 viewController.myMethod()
 anotherViewController.myMethod()

Not only that, in addition to the methods that have been defined, we can even add methods that are not defined in the protocol to the extension. In these additional methods, we can rely on the methods defined in the protocol to perform operations. We will see more examples later. To sum up:

• Protocol Definition
  • Provide an entry point for implementation
  • Types that conform to a protocol need to implement it
• Protocol Extensions
  • Provides a default implementation for entry
  • Provide additional implementation based on entry

In this way, cross-cutting concerns are solved simply and safely.

• Dynamic dispatch security
• Cross-cutting concerns
• Diamond defect

3.1.3 Diamond defect

Finally, let's look at multiple inheritance. An important problem in multiple inheritance is the diamond defect, that is, the subclass cannot determine which parent class method to use. In the corresponding aspect of the protocol, although this problem still exists, it can be uniquely and safely determined. Let's look at an example of elements with the same name appearing in multiple protocols:

 protocol Nameable
 var name : String { get }
 } 
 
 protocol Identifiable
 var name : String { get }
 var id: Int { get }
 }

If a type needs to implement two protocols at the same time, it must provide a name property to meet the requirements of both protocols:

 struct Person: Nameable, Identifiable {
 let name : String
 let id: Int  
 } 
 
 // The ` name` property satisfies both Nameable and Identifiable names  

What's interesting here, and a bit confusing, is what happens if we extend one of the protocols and provide a default name implementation. Consider the following code:

 extension Nameable {
    var name : String { return   "default name" }
 } 
 
 struct Person: Nameable, Identifiable {
 // let name : String
 let id: Int  
 } 
 
 // Identifiable will also use the name from the Nameable extension  

This compilation is OK. Although name is not defined in Person, Person can still comply with Identifiable through the name of Nameable (because it is statically assigned). However, when both Nameable and Identifiable have the protocol extension of name, it will not compile:

 extension Nameable {
    var name : String { return   "default name" }
 } 
 
 extension Identifiable {
    var name : String { return   "another default name" }
 } 
 
 struct Person: Nameable, Identifiable {
 // let name : String
 let id: Int  
 } 
 
 // Cannot compile, name attribute conflicts

In this case, Person cannot determine which protocol extension to use for the definition of name. When implementing two protocols with the same name and both provide default extensions, we need to explicitly provide the implementation in the specific type. Here we just implement name in Person:

 extension Nameable {
    var name : String { return   "default name" }
 } 
 
 extension Identifiable {
    var name : String { return   "another default name" }
 } 
 
 struct Person: Nameable, Identifiable {
 let name : String
 let id: Int  
 } 
 
 Person( name : "onevcat" , id: 123). name // onevcat

The behavior here looks very similar to the diamond problem, but there are some essential differences. First, the prerequisite for this problem to occur is that the elements with the same name and the implementation are provided at the same time, while the protocol extension is not necessary for the protocol itself.

Secondly, the implementation we provide in the specific type must be safe and certain. Of course, the diamond defect has not been completely solved, and Swift cannot handle conflicts between multiple protocols well, which is the current shortcoming of Swift.

• Dynamic dispatch security
• Cross-cutting concerns
• Diamond defect

Author: Wang Wei (onevcat), also known as "Cat God" in the industry, is the initiator and leader of the ObjC China organization and the author of the famous open source framework Kingfisher.