Using Nsproxy and NSObject to design differences in proxy classes

It is often found that when you create a proxy class using message forwarding, different programmers have different ways of using it, some of them inherit from NSObject, and some inherit from Nsproxy. Both are base classes in the foundation framework, and both implement <NSObject> this interface, and nsproxy is inherently used to do this in naming and documentation. But even so, they all define the same interface for message forwarding. What difference do we make when we use both to do this work?

Let's put it first. The most basic implementation code that creates a proxy class by both.

Inherit from Nsproxy

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

@interfaceThproxya:Nsproxy @property (Nonatomic,Strong)ID target; @end @implementationThproxya - (ID) Initwithobject: (ID) Object { self.target = object; return self; -(Nsmethodsignature *) Methodsignatureforselector: (SEL) Selector { return [ self.target methodsignatureforselector:selector]; -(void) Forwardinvocation: (nsinvocation *) invocation { [invocation Invokewithtarget: self.target]; @end

Inherit from NSObject

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21st 22 23

@interfaceTHPROXYB:NSObject @property (Nonatomic,Strong)ID target; @end @implementationThproxyb - (ID) Initwithobject: (ID) Object { Self = [Super Init]; if (Self) { self.target = object; return self; -(Nsmethodsignature *) Methodsignatureforselector: (SEL) Selector { return [ self.target methodsignatureforselector:selector]; -(void) Forwardinvocation: (nsinvocation *) invocation { [invocation Invokewithtarget: self.target]; @end

The code is basically consistent, except for the specifics of the specification when initializing, because the base class of Nsproxy does not define the default Init method.

1. After testing, the following two <NSObject> defined interfaces are found to be inconsistent between the two:

1 2 3 4 5 6 7 8 9

NSString *string =@ "test"; thproxya *proxya = [[Thproxya alloc] initwithobject:string]; thproxyb *proxyb = [[Thproxyb alloc] initwithobject:string]; nslog (@ "%d", [Proxya Respondstoselector: @selector (length)]); nslog (@ "%d", [Proxyb Respondstoselector: @selector (length)]); nslog (@ "%d", [Proxya Iskindofclass:[nsstring class]); nslog (@ "%d", [Proxyb Iskindofclass:[nsstring class]); /span>

The result will be output to accomplish different conclusions:

1 2

1 0 1 0

That is, by inheriting from the NSObject proxy class is not automatically forwarded Respondstoselector: and Iskindofclass: These two methods, and inherit from the Nsproxy proxy class is possible. The <NSObject> other interfaces defined in the test are consistent in their performance.

The methods defined in all category 2.NSObject cannot be forwarded in THPROXYB

As a very common example, Valueforkey: Is the way to define the nskeyvaluecoding in this nsobject category and try to perform the performance of both.

1 2	NSLog (@"%@", [Proxya valueforkey:@"Length"]); NSLog (@"%@", [Proxyb valueforkey:@"Length"]);

The first sentence of this code can run correctly, but the second line throws an exception, the analysis of the final reason is very simple, because Valueforkey: is the nsobject category defined in the method, let NSObject have such an interface, Message forwarding is only possible when the recipient is unable to process the forwardinvocation: to seek the object that can be processed.

3. Conclusion: It seems that nsproxy is indeed better suited to implement proxy classes as message forwarding because, as an abstract class, the Nsproxy itself can handle very little (only <NSObject> some of the methods defined in the interface), so other methods can be forwarded to the Proxied object as expected by the design.

Use Nsproxy and nsobject to design differences in proxy classes