IOS Program Guide: Imitating multiple inheritance in Objective-C

First, I have to say that. Although this technique is not complex at all, it requires programmers to understand their own code. Objective-C does not support multi-inheritance because of its reasons. Multi-inheritance allows us to combine the features of many different objects. Most of the results will make your objects large and have multiple interfaces. In iPhone development, we are more often used and more suitable for the fine-grained design of the object to complete our own functions. In fact, the method to be introduced is only an imitation of inheritance. It also tends to encourage your objects to become sophisticated and perform their respective duties. All of this is provided by the Objective-C Runtime Library.

 

Of course, why do we need to use multi-inheritance? Multi-inheritance has significant benefits in some specific scenarios. For example, when we design a game (I especially like to use Starcraft as an example), we design an object named base and a second object named mother ship core. Obviously, these two objects should inherit different parent classes: buildings and units. But one day, our game designers thought that they should give the mother ship a core skill so that they can transfer their attack capabilities to the base so that the base can attack. What should we do at this time? We can write a separate attack method for the base. Or we can simply (in the case of multi-inheritance) Let the base inherit from the mother ship's core, so that we can borrow some methods of the mother ship's core.

 

Of course, as long as the game is not tied to Objective-C. However, there are many similar scenarios. Objective-C understands this and then provides us with a solution. That is, message forwarding during running.

-(Void) forwardInvocation :( NSInvocation *) anInvocation;

It works like this. When an object receives an undefined message, it does not throw an exception immediately and then let the call stack capture it. Instead, it provides a second opportunity to call forwardInvocation: this method is used to send the message to other objects for processing. (Other objects you define include reference objects .) The NSInvocation class encapsulates the message name and a series of information about the passed parameters. In this way, the message can be handed over to other objects based on the nature of the message. The return value will also be returned to us, so that our own object will work in the same way as another object on the far end.

 

What are the benefits of doing so? First, if your object has defined this method, forwardInvocation will not be triggered, which is similar to function rewriting. Second, compared to writing a method by yourself, from the developer's perspective, the other objects you seek may not only be able to process this message, it is very likely that it will also handle other issues that you should handle but can only be found at runtime (for example, after a certain time point, the other party upgrades the objects they provide .) Therefore, the use of such a mechanism for message forwarding at runtime can be a good imitation of the Multi-inheritance function, by the way, retaining the exquisite features of Objective-C.

 

Third, this method provides us with a very good model. That is, the mode used by NSProxy is another major root class outside NSObject in the Cocoa framework. Sometimes, we will encounter some very large objects. It may be a Singleton, or something else. Most of the time, we only need to get some of its descriptive information (What do we think of, streaming media or the network ?) You do not need to use it. Because initialization of such a class consumes too much resources, we hope to delay this operation as much as possible: the best case is not to do it! At this time, we can design a lightweight front-end object that can handle most received messages. When we receive undefined messages, and then forward it to the huge object behind it: At this time, the object Singleton will be called for initialization. From the user's point of view, this front-end lightweight object performs exactly as expected. Do you think this is cool?

 

Of course, such a method cannot be left empty. First, the series of methods such as respondsToSelector still think that they cannot respond to the messages to be forwarded. Second, the object that throws an exception is no longer your object but the remote object. So what did Oops start? To use this technique, you must have a deep understanding of your own objects and the target objects for message forwarding. As Apple's official document says: If it's not exactly the same, never use it!