We often confuse the following three statements (which I have not noticed):
1. ID foo1;
2. NSObject *foo2;
3. id<nsobject> Foo3;
The first is the most frequently used, it simply states that pointers to objects are not given to the compiler regardless of type information, so the compiler does not do type checking. But also because of this, you can send no matter what information to the ID type of the object. This is why +alloc returns the ID type, but calling [[Foo alloc] init] does not produce a compilation error.
&NBSP; Therefore, the ID type is the dynamic type at execution time. The compiler cannot know its true type, even if you send a method with an ID type that does not have a compile warning.
&NBSP; we know, The ID type is a Objective-c object, but not all points to an object that inherits from Nsojbect, even though the type and NSObject object have very many common methods, such as retain and release. To let the compiler know that this class inherits from NSObject, a workaround is to use the NSObject static type, as in the 2nd, when you send a method that NSObject does not have, like length or count, the compiler gives a warning. This also means that you can safely use these methods like Retain,release,description.
Therefore, declare a generic NSObject object pointer similar to what you do in other languages, like Java, but other languages have certain limitations, Not as flexible as objective-c. Not all Foundation/cocoa objects inherit nsobject, for example Nsproxy does not inherit from NSObject, so you cannot use nsobject* to point to this object. Even if the Nsproxy object has the general method of release and retain. To solve the problem, you need a pointer to the object that owns the NSObject method, which is the 3rd usage scenario.
the ID tells the compiler that you don't care what type of object it is, but it must comply with the NSObject Protocol (protocol), The compiler can guarantee that all objects assigned to the ID type are subject to the NSObject Protocol (Protocol). This pointer can point to whatever NSObject object, because the NSObject object complies with the NSObject Protocol (Protocol), and it can also be used to save Nsproxy objects because it also complies with the NSObject Protocol (Protocol). It's powerful, convenient, and flexible, and you don't have to worry about what kind of object it is, but just how it's implemented.
now you know what type you're going to use, don't you?
Suppose you do not need any type checking, use ID, it is often used as the return type, and often is usually applied to the declaration Agent (delegate) type. Because the proxy type is usually executed, the methods are checked for implementation.
Assuming that you really need a compiler check, consider using a 2nd or 3rd type. It is very rare to see nsobject* perform properly, but the ID does not perform properly. The advantage of using a protocol (protocol) is that it can point to Nsproxy objects, and more often, you just want to know what protocol an object adheres to, rather than what type it is.
ios_oc_id, NSObject, id< Nsobject> Difference
