What's the difference between declaring a variable "ID" and "nsobject *"?

with a variable typed id , you can send it any known message and the compiler will not complain. with a variable typed nsobject * , you can only send it messages declared by nsobject (not methods of any subclass) or else it will generate a warning. in general, id is what you want.

IDMeans "an object ",Nsobject *Means "an instanceNsobjectOr one of its subclasses ". There are objects in objective-C which are notNsobjectS (the ones you'll meet in cocoa at the moment areNsproxy,ProtocolAndClass). If some code expects an object of a particle class, declaring that helps the compiler check that you're using it properly. if you really can take "any object"-for instance you are declaring a delegate and will test all method sendsRespondstoselector:Cballs-you can useID.

Another way to declare an object variable is like"ID <nsobject>", Which means" any object which implementsNsobjectProtocol.

 

 

There's often confusion about the difference between the following three declarations in objective-C:

 

1. Id foo1;
   
2. Nsobject * foo2;
   
3. ID <nsobject> foo3;
   

The first one is the most common. It simply declares a pointer to some objective-C object (see /Usr/include/objc. h ). ID Gives the compiler no information about the actual type of the object, so the compiler cannot do compile-time type checking for you. thus, the compiler will let you send any (*) message to objects declared ID . Actually, this is why the common idiom [[Foo alloc] init] Doesn't cause the compiler to complain. + Alloc Is declared to return type ID , So the compiler won't yell when you then send the returned object the message Init (Or even Initwithmyfoo: Blah ).

So, objects declared usingIDAre just dynamically typed at runtime. the compiler has no useful information about the object's real type, so it can't warn you if you send it a message that it may not respond.

Just because we know that ID Is an objective-C object does Not Mean that it points to an object that derives from nsobject, or that it even has common methods like retain and release. One solution is to statically type our variable using Nsobject * As shown in Number 2 above. This gives the compiler information about the class of the object pointed to Foo2 So the compiler can warn if you send a message Foo2 That Nsobject Doesn't respond to. This means you can safely call retain, release, description, Etc., but the compiler will warn if you call Length Or Count Or anything that an nsobject doesn't respond.

SO, declaring a generic pointer of Type nsobject * is very similar to what you woshould do in other ages, like Java, but it's really a bit too restrictive for a language as flexible as objective-C. despite what you may have learned at one point, not all Foundation/cocoa objects derive from nsobject. as an example, nsproxy is not derived from nsobject, so the foo2 pointer above wocould not be able to hold an nsproxy subclass, even though nsproxy does implement common methods like retain and release. what you really want is a pointer to Any object that behaves like an nsobject. and that's exactly what the third case does.

declaring an object as id tells the compiler that you don't care what type the object is, but you do care that it conforms to the specified nsobject protocol **. the compiler will ensure that all objects you assign to that pointer conform to the required protocol. A pointer typed like this can safely hold any nsobject (because nsobject conforms to the nsobject protocol), but it cocould also hold any nsproxy, because nsproxy also conforms to the nsobject Protocol. in English, the Declaration id foo3; says "foo3 is a pointer to an object of any type that behaves like an nsobject ". this is very powerful, convenient, and expressive. in reality, we often don't care what type an object is, we just care that it responds to the messages that we want to send it (e.g ., retain, release ).

so how do you decide which form you want to use? It's pretty easy. if you don't want (or can't have) any type checking, then use a plain id . this is very common for return types on methods that don't know the type of object they re returning (e.g ., + alloc ). it is also common to declare delegates to be type id , because delegates are generally checked at runtime with respondstoselector: , and they usually aren't retained.

However, if you do want compile-time type checking, you must decide between the second and third cases. Well, let me just help you out-you want the third case! I 've very, very, very rarely seen a situation whereNsobject *WorkedID <nsobject>Wocould not. and using the Protocol form has the advantage that it will work with nsproxys. you may think that you never use nsproxys, but cocoa's distributed objects system makes heavy use of nsproxy subclasses. additionally, the common case is that you simply want to ensure that an object can be retained or released, and in that case the Protocol form conveys that intent better; you really don't care what class the object is, you only care that itBehavesLike an nsobject.

 

By the way, from using protocols in learning objective-C 2.0

 

Tableprinter
Listing 13.2 shows the header file forTableprinterClass:

Listing 13.2.Tableprinter/tableprinter. h

 
# Import <Foundation/Foundation. h>
@ Protocol tableprinterdatasource; @ interface tableprinter: nsobject
{Id <tableprinterdatasource> datasource;
} @ Property (nonatomic, assign) ID <tableprinterdatasource> datasource;-(void) printtable; @ end
 

 

Listing 13.3.Tableprinter/tableprinter. m

# Import "tableprinter. H" # import "tableprinterdatasource. H" @ implementation tableprinter
@ Synthesize datasource;-(void) printtable {nsstring * Separator = @"-------------------------";
Nsstring * Title = @ "table"; if ([datasourceRespondstoselector: @ Selector (tabletitle)])
{Title = [datasource tabletitle];
} Printf ("\ n % s \ n", [Title utf8string], [separator utf8string]); int numrows = [datasource numberofrowsintable]; Int J; bool printlinenumbers = no; If ([datasource respondstoselector: @ selector (printlinenumbers)]) {}
 

 

A Problem

Although the program worked, you shoshould have noticed a small problem when you built it; some compiler Warnings such as the following:

Tableprinter. M: 23: Warning: '-respondstoselector:' not found in protocol (s)

The compiler is complaining thatRespondstoselector:Isn' t part of<Tableprinterdatasource>Protocol. It isn't, but it shouldn't matter becauseRespondstoselector:Is IMPLEMENTEDNsobject,And every object (including the object passed in as the data source) inherits fromnsobject. And it doesn't matter-the program worked just fine, didn't it? Well, yes, but it's a bad idea to get in the habit of ignoring compiler warnings, even semi-spurous ones. if you start ignoring warnings, one day, as sure as the sun rises, you'll ignore one that isn't spurous and there will be trouble.

You can fix this in one of two ways. InTableprinter. H,You can change the type in the instance variable and property declarations:

Nsobject <tableprinterdatasource> * datasource;

This tells the compiler explicitly thatDatasourceIs a subclassNsobjectAs well as implementing<Tableprinterdatasource>.A more elegant solution is to change@ ProtocolLine inTableprinterdatasource. hTo be:

@ Protocol tableprinterdatasource <nsobject>

This means that anything that adopts<Tableprinterdatasource>Also adopts<Nsobject>Protocol. (this includes strates the important point that one protocol can adopt another .)<Nsobject>Is a protocol thatNsobjectAdopts (see the sidebar,NsobjectAnd<Nsobject> ).Again, becauseNsobjectImplementsRespondstoselector :,You don't have to do any work beyond making the compiler understand that everythingIs OK.

 

Nsobject and <nsobject>

This can be a bit confusing (Confused ).<Nsobject>Is a formal protocol that lists the methods that any class must implement to be a good objective-C citizen (citizen). These are some of the very basic methods likeRespondstoselector:, superclass,And the reference countingRetainAndRelease.(For a complete list, see the header fileNsobject. H .)Nsobject(The class) adopts<Nsobject>Protocol and then most classes acquire these methods by inheriting, directly or indirectly, fromNsobject. nsproxy,Foundation's other root class (used for building distributed systems), also adopts<Nsobject>.

 

Protocol objects and testing for conformance

Protocol objects are objects that represent protocols. They are members of the classProtocol. YouObtain a protocol object from the Protocol's name with@ Protocol ()Directive:

Protocol myperformanceprotocol = @ protocol (tableprinterdatasource );

Unlike class objects, protocol objects have no methods and their use is confined to being an argument toNsobjectMethodConformstoprotocol:. ThisMethod returnsYesIf the specified er implements all the required methods in the protocol andNoOther-wise. You cocould use a protocol object to build a safer versionTableprinterBy Cod-ing the accessor methods forDatasourceInstance variable yourself and doing a bit of extra work. A safer setter is shown in listing 13.7.

Listing 13.7.A safer setter forTableprinterData Source

-(Void) setdatasource: (ID <tableprinterdatasource>) newdatasource
{If (! [Newdatasource conformstoprotocol: @ protocol (tableprinterdatasource)]) {datasource = nil; nslog (@ "tableprinter: non-conforming data source .");}
Elsedatasource = newdatasource ;}
 

 

The preceding version of setdatasource: prevents assigning an object that does not conform to the <tableprinterdatasource> protocol as the datasource. if such an object were assigned as the datasource, it wowould likely cause a crash when one of the required protocol methods was invoked.

Nsobject also has a class method conformstoprotocol: that you can use to test if a class (rather than instance of a class) conforms to a protocol. The following wowould return YES:

[Fruitbasket conformstoprotocol: @ protocol (tableprinterdatasource)];

Testing for Protocol Conformance is an example of defensive coding. With a few extra lines of code, you can prevent a run time crash.

Informal (informal) Protocols

The protocols discussed so far (so far) in this chapter are calledFormal (formal)Protocols. A formal proto-Col is declared with@ ProtocolStatement. classes that adopt a formal protocol are marked with<Protocolname>On the class's@ InterfaceLine. Objective-C also hasInformalProtocols. Like formal protocols, informal protocols are a group of related meth-ODS that a class might want to implement. An informal Protocol declares its methods in a category (usually a category onNsobject ),But without a corresponding category implementation:

@ Interface nsobject (myinformalprotocol)

-(Void) informalprotocolmethod;

@ End

An informal protocol is actually in the nature of a gentle-person's agreement on the part of the programmer writing a class that adopts the protocol. the programmer agrees to implement the informal protocol's methods when coding that class, but the compiler does nothing to check that he or she follows through on the agreement. the category functions as a piece of documentation listing the methods in the Protocol. there is no type checking at compile time and no way of determining at run time if a class imple-ments an informal protocol. classes that adopt an informal protocol must declare the Protocol methods in their interface section and put the code for those methods in their implementation section.

Note

when you code a class that adopts an informal protocol, the Protocol method implementations must go in the class's @ implementation section, not In a Category @ implementation section. if you place the implementations in a separate category @ implementation sec-tion, your method implementations are added to all classes (assuming the protocol is declared as a category on nsobject ). This is unlikely to be what you intended to do.

So what's the point of using informal protocols? Before objective-C 2.0, all the methods in a formal protocol were required. the only way to have optional methods in a proto-Col was to use an informal protocol and note the optional methods in the specified Enta-tion. with the advent@ OptionalAnd@ Required,There isn't much reason to use an informal Protocol: You can have optional methods and still enjoy the benefits of a formal protocol.

You can see this progression in the Apple frameworks: in earlier versions of the appkit,Nstabledatasource(The data source protocol for appkit'sNstableview)Was an informal protocol. Beginning in Mac OS X snow leopard (V 10.6 ),NstabledatasourceHas been replaced withNstableviewdatasourceFormal protocol.

Summary

Protocols add flexibility to program design by lew.you type objects by behavior rather than by class. there are invalid situations where all that is required of an object is that it implement a participant set of methods. in these situations, the object's class and other behavior are immaterial. protocols let you formalize this pattern:

You declare a protocol by giving it a name and declaring its methods@ ProtocolAnd@ EndDirectives.

Protocol methods may be either@ RequiredOr@ Optional.

A class adopts a protocol by implementing all of the Protocol's required methods and, perhaps, some or all of the Protocol's optional methods. the class advertises that it has adopted the Protocol by appending the protocol name inside angle brackets after the superclass name on the class's @ interface line. the header file containing the Protocol Declaration must be visible to the adopting class's @ inter-face section.

You can add a protocol name to the type declaration of an instance variable or a method argument. if you do this, the compiler checks to see that an object that you assign to the instance variable or use as the method argument adopts the spec-ified protocol.

You can use the class or the instance versionConformstoprotocol:To see if a given class or a given object adopts a participant protocol.

Before calling@ OptionalMethod, you shocould useRespondstoselector:To make sure the assumer has implemented the method.

The protocols described in the preceding points are called formal protocols. there are also informal protocols, which are just a list of methods that a class might choose to implement. there is no compiler support for checking informal proto-cols. they were originally used to declare protocols that had optional methods. with the introduction of the @ optional directive in objective-C 2.0, there is no reason to use an informal protocol instead of a formal protocol.