这点很有意思，理清楚了Message Forward的过程（特别那个例子有意思），但是感觉 具体例子太少了~~ 难道是我没有理解透？

Item 12: Understand Message Forwarding

Item 11 explains why it’s important to understand the way messages are sent to objects. Item 12 explores why it’s important to understand what happens when a message is sent to an object that it doesn’t understand.

A class can understand only messages that it has been programmed to understand, through implementing methods. But it’s not a compile-time error to send a message to a class that it doesn’t understand, sincemethods can be added to classes at runtime so the compiler has no way of knowing whether a method implementation is going to exist. When it receives a method that it doesn’tunderstand, an object goes through message forwarding, a process designed to allow you as the developer to tell the message how to handle the unknown message.

Even if you are unaware of it, you will very likely already have encountered messages going through the message-forwarding pathways. Every time you’ve seen a message such as the following in the console, it’s because you’ve senta message to an object that it doesn’t understand and the default NSObject implementation of the forwarding path has kicked in:

Click here to view code image

-[__NSCFNumber lowercaseString]: unrecognized selector sent to
instance 0x87
*** Terminating app due to uncaught exception
'NSInvalidArgumentException', reason: '-[__NSCFNumber
lowercaseString]: unrecognized selector sent to instance 0x87'

This is an exception being thrown from NSObject’s method calleddoesNotRecognizeSelector: telling you that the receiver of the messageis of type__NSCFNumber and that it doesn’t understand the selector lowercaseString. That’s not really surprising in this case, since NSNumber (__NSCFNumber isthe internal class used in toll-free bridging—see Item 49—which is created whenyou allocate anNSNumber). In this case, the forwarding pathways ended in the application’s crashing, but you can hook into the forwarding pathways in your own classes to perform any desired logic instead of crashing.

The forwarding pathways are split into two avenues. The first gives the class to which the receiver belongs a chance to dynamically add a method for theunknown selector. This is called dynamic method resolution. The second avenue is the full forwarding mechanism. If the runtime has made it this far, it knows that there’sno longer a chance for the receiver itself to respond to the selector. So it asks the receiver to try to handle the invocation itself. It does this in two steps. First, it asks whetheranother object should receive the message instead. If there is, the runtime diverts the message, and everything proceeds as normal. If there is no replacement receiver, the full forwarding mechanism is put into effect, using the NSInvocation objectto wrap up the full details about the message that is currently unhandled and gives the receiver one final chance to handle it.

+ (BOOL)resolveInstanceMethod:(SEL)selector

This method takes the selector that was not found and returns a Boolean to indicate whether an instance method was added to the class that can now handlethat selector. Thus, the class is given a second opportunity to add an implementation before proceeding with the rest of the forwarding mechanism. A similar method, called resolveClassMethod:, is calledwhen the unimplemented method is a class method rather than an instance method.

Using this approach requires the implementation of the method to already be available, ready to plug in to the class dynamically. This method is often used to implement @dynamic properties(see Item 6), such as occurs in CoreData for accessing properties of NSManagedObjects,since the methods required to implement such properties can be known at compile time.

Such an implementation of resolveInstanceMethod: for use with @dynamicproperties might look like this:

Click here to view code image

id autoDictionaryGetter(id self, SEL _cmd);
void autoDictionarySetter(id self, SEL _cmd, id value);

+ (BOOL)resolveInstanceMethod:(SEL)selector {
NSString *selectorString = NSStringFromSelector(selector);
if ( /* selector is from a @dynamic property */ ) {
if ([selectorString hasPrefix:@"set"]){
class_addMethod(self,
selector,
(IMP)autoDictionarySetter,
"v@:@");
} else {
class_addMethod(self,
selector,
(IMP)autoDictionaryGetter,
"@@:");
}
return YES;
}
return [super resolveInstanceMethod:selector];
}

The selector is obtained as a string and then checked to see whether it looks like a setter. If it is prefixed with set, it is assumed to be a setter; otherwise, it is assumed to bea getter. In each case, a method is added to the class for the given selector pointing to an implementation defined as a pure C function. In these C functions there would becode to manipulate whatever data structure was being used by the class to store the properties’ data. For example, in the case of CoreData, these methods would talk to the database back end to retrieve or update values accordingly.

- (id)forwardingTargetForSelector:(SEL)selector

The unknown selector is passed in, and the receiver is expected to return the object to act as its replacement or nil if no replacement can befound. This method can be used to provide some of the benefits of multiple inheritance by combining its use with composition. An object could own a range of other objects internally that it returns in this method for selectors that they handle, makingit look as though it is itself handling them.

Note that there is no way to manipulate the message using this part of the forwarding path. If the message needs to be altered before sending to the replacement receiver, the full forwarding mechanism must be used.

The method that gets called to attempt forwarding this way is:

- (void)forwardInvocation:(NSInvocation*)invocation

A simple implementation would change the target of the invocation and invoke it. This would be equivalent to using the replacement receiver method, so such a simple implementation is rarely used. A more useful implementation wouldbe to change the message in some way before invoking it, such as appending another argument or changing the selector.

An implementation of this method should always call its superclass’s implementation for invocations it doesn’t handle. This means that once all superclasses in the hierarchy have been given a chance to handle the invocation, NSObject’simplementation will be called. This invokes doesNotRecognizeSelector: to raise the unhandled selector exception.

At each step, the receiver is given a chance to handle the message. Each step is more expensive than the one before it. The best scenario is that the method is resolved at the first step, since the method that was resolved willend up being cached by the runtime such that forwarding does not have to kick in at all next time the same selector is invoked on an instance of the same class. At the second step, forwardinga message to another receiver is simply an optimization of the third step for the case in which a replacement receiver can be found. In that case, the only thing that needs to be changed about the invocation is the target, which is much simpler to do thanthe final step, in which a complete NSInvocation needs to be created and handled.

Full Example of Dynamic Method Resolution

To illustrate how forwarding can be useful, the following example shows the use of dynamic method resolution to provide @dynamic properties. Consider an object that allows you to storeany object in it, much like a dictionary, but provides access through properties. The idea of the class will be that you can add a property definition and declare it @dynamic, and the class will magically handlestoring and retrieving that value. That would be pretty fantastic, right?

The interface for the class will be like this:

Click here to view code image

#import <Foundation/Foundation.h>

@interface EOCAutoDictionary : NSObject
@property (nonatomic, strong) NSString *string;
@property (nonatomic, strong) NSNumber *number;
@property (nonatomic, strong) NSDate *date;
@property (nonatomic, strong) id opaqueObject;
@end

It doesn’t particularly matter for this example what the properties are. In fact, I’ve shown a variety of types just to illustrate the power of this feature. Internally, the values for each property will be held in a dictionary,so the start of the implementation of this class would look like the following, including declaring the properties as @dynamic suchthat instance variables and accessors are not automatically created for them:

Click here to view code image

#import "EOCAutoDictionary.h"
#import <objc/runtime.h>

@interface EOCAutoDictionary ()
@property (nonatomic, strong) NSMutableDictionary *backingStore;
@end

@implementation EOCAutoDictionary

@dynamic string,number, date, opaqueObject;

- (id)init {
if ((self = [super init])){
_backingStore = [NSMutableDictionary new];
}
return self;
}

Then comes the fun part: the resolveInstanceMethod: implementation:

Click here to view code image

+ (BOOL)resolveInstanceMethod:(SEL)selector {
NSString *selectorString = NSStringFromSelector(selector);
if ([selectorString hasPrefix:@"set"]){
class_addMethod(self,
selector,
(IMP)autoDictionarySetter,
"v@:@");
} else {
class_addMethod(self,
selector,
(IMP)autoDictionaryGetter,
"@@:");
}
return YES;
}

@end

The first time it encounters a call to a property on an instance of EOCAutoDictionarythe runtime will not find the corresponding selector, since they’re not implemented directly orsynthesized. For example, if the opaqueObject property is written, the preceding method will be invoked with a selector of setOpaqueObject:. Similarly, if the propertyis read, it will be invoked with a selector of opaqueObject. The method detects the difference between set and get selectorsby checking for a prefix of set. In each case, a method is added to the class for the given selector pointing to a function called either autoDictionarySetter or autoDictionaryGetter, asappropriate. This makes use of the runtime method class_addMethod, which adds a method dynamically to the class for the given selector,with the implementation given as a function pointer. The final parameter in this function is the type encoding of the implementation. The type encoding is made up from characters representingthe return type, followed by the parameters that the function takes.

The getter function would then be implemented as follows:

Click here to viewcode image

id autoDictionaryGetter(id self, SEL _cmd){
// Get the backing store from the object
EOCAutoDictionary *typedSelf = (EOCAutoDictionary*)self;
NSMutableDictionary *backingStore = typedSelf.backingStore;

// The key is simply the selector name
NSString *key = NSStringFromSelector(_cmd);

// Return the value
return [backingStore objectForKey:key];
}

Finally, the setter function would be implemented like this:

Clickhere to view code image

void autoDictionarySetter(id self, SEL _cmd, id value){
// Get the backing store from the object
EOCAutoDictionary *typedSelf = (EOCAutoDictionary*)self;
NSMutableDictionary *backingStore = typedSelf.backingStore;

/** The selector will be for example, "setOpaqueObject:".
*  We need to remove the "set", ":" and lowercase the first
*  letter of the remainder.
*/
NSString *selectorString = NSStringFromSelector(_cmd);
NSMutableString *key = [selectorString mutableCopy];

// Remove the ':' at the end
[key deleteCharactersInRange:NSMakeRange(key.length - 1, 1)];

// Remove the 'set' prefix
[key deleteCharactersInRange:NSMakeRange(0, 3)];

// Lowercase the first character
NSString *lowercaseFirstChar =
[[key substringToIndex:1] lowercaseString];
[key replaceCharactersInRange:NSMakeRange(0, 1)
withString:lowercaseFirstChar];

if (value) {
[backingStore setObject:value forKey:key];
} else {
[backingStore removeObjectForKey:key];
}
}

Using EOCAutoDictionary is then a simple matter of the following:

Click here to viewcode image

EOCAutoDictionary *dict = [EOCAutoDictionary new];
dict.date = [NSDate dateWithTimeIntervalSince1970:475372800];
NSLog(@"dict.date = %@", dict.date);
// Output: dict.date = 1985-01-24 00:00:00 +0000

The other properties on the dictionary could be accessed just like the date property, and new properties could be introduced by adding a @property definitionand declaring it @dynamic. A similar approachis employed by CALayer, part of the CoreAnimation framework on iOS. This approach allows CALayer to be a key-value-coding-compliant container class, meaning thatit can store a value against any key.CALayer uses this ability to allow the addition of custom animatable properties whereby the storage of the property values is handled directly by the base class, but the propertydefinition can be added in a subclass.

 Dynamicmethod resolution is used to add methods to a class at runtime as and when they are used.

 Objects can declare that another object is to handlecertain selectors that it doesn’t understand.

 Full forwarding is invoked only when no previousway of handling a selector has been found.