Knowledge points that are very important and commonly used in iOS development, but are easy to ignore: ID, nsobject, Id difference

We often confuse the following three statements (I did not pay attention to them ):

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

The first type is the most common. It simply declares the pointer to the object and does not give the compiler any type information. Therefore, the compiler does not perform type checks. But because of this, you can send any information to the ID type object. This is why + alloc returns the ID type, but calling [[Foo alloc] init] will not produce compilation errors.

Therefore, the ID type is a dynamic type during runtime, And the compiler cannot know its actual type. Even if you send a method without the ID type, no compilation warning is generated.

We know that the ID type is an objective-C object, but not all point to the object inherited from nsojbect, even if this type and nsobject object have many common methods, such as retain and release. To let the compiler know that this class inherits from nsobject, one solution is to use the nsobject static type like the 2nd method. When you send a method that is not available for nsobject, such as length or count, the compiler will give a warning. This also means that you can safely use methods such as retain, release, and description.

Therefore, declare that a universal nsobject Object Pointer is similar to what you do in other languages, such as Java, but other languages have certain limitations and are not as flexible as objective-C. Not all Foundation/cocoa objects inherit nsobject. For example, nsproxy does not inherit nsobject, so you cannot use nsobject * to point to this object, even if the nsproxy object has a general method such as release and retain. To solve this problem, you need a pointer to the nsobject method object. This is the usage scenario of the 3rd statements.

ID <nsobject> tells the compiler that you do not care about the object type, but it must comply with the nsobject protocol (Protocol ), the compiler ensures that all objects assigned to the ID <nsobject> type comply with the nsobject protocol (Protocol ). Such a pointer can point to any nsobject object because the nsobject object complies with the nsobject protocol and can also be used to save the nsproxy object because it also complies with the nsobject protocol (Protocol ). This is very powerful, convenient, and flexible. You don't have to worry about the object type, but only about the methods it implements.

Now you know what type you want to use, right?

If you do not need any type check, use ID, which is often used as the return type, and often used to declare the proxy (delegate) type. Because the proxy type is usually running, it checks whether the methods are implemented.

If you really need a compiler check, consider using 2nd or 3rd. It is rarely seen that nsobject * can run normally, but Id <nsobject> cannot run normally. The advantage of using a protocol is that it can point to an nsproxy object. More often, you only want to know which Protocol an object complies with, rather than what type it is.