In the obj-C world, there is no such official saying as "interface" or "generic. However, there are two concepts close to OBJ-C: "Informal protocol" and "formal protocol )". Although the keyword of the informal protocol in obj-C is also interface, this is not exactly the same as the interface in C. Recall what we have learned before. When we define a sample class, we always convert it into a sample. h. The Code is as follows:
#import <Foundation/Foundation.h>@interface Sample : NSObject {}-(void) HelloWorld;@end
It indicates that there is a method named helloworld in the sample class that stipulates "should" (Note: what I am talking about here is yes, not a must). It is just a gentleman agreement.
If we do not comply with this convention in sample. m (that is, do not implement this method), xcode will give a warning during compilation, as shown in. But it will still be compiled successfully at the end (that is, the compiler closes one eye with one eye, which defaults to this kind of cheating behavior of the sample class)
Note: incomplete implementation of Class "sample". Meaning: The sample class does not fully implement the methods agreed in interface. This is where the protocol in obj-C is different from the interface in C #: the interface in C # is mandatory and must be implemented; otherwise, compilation will fail, while obj-C will warn during compilation, it can finally be compiled. The formal protocol (Protocal) is actually an informal protocol (interface). It looks more formal and more semantic: classes that require the protocol, "must" implement the methods agreed in the Protocol. However, it is entertaining that, even if it is known as a formal protocol, the compiler still gives a warning when it encounters noncompliance during compilation. (Of course, the formal protocol also has its meaning, which will be mentioned later) Here we define an IQUERY protocol IQUERY. h.
@protocol IQuery-(void) Query:(NSString*) sql;@end
In addition to changing the keyword @ interface to @ protocal, the others are basically unchanged. The following defines a class dbquery and uses this formal protocol dbquery. h
#import <Foundation/Foundation.h>#import "IQuery.h"@interface DBQuery : NSObject<IQuery> {}@end
Note that dbquery: nsobject <IQUERY> indicates that dbquery inherits from nsobject.
ProtocolIQUERY. Dbquery. m
#import "DBQuery.h"@implementation DBQuery-(void) Query:(NSString *)sql{NSLog(@"Query is called. sql:%@",sql);}@end
Of course, if you do not implement the method query in dbquery. M, you can compile and pass the query, but you will receive a warning. So far, you may think that protocal and interface are similar concepts. protocal design is purely redundant. In fact, protocal has an important significance: the formal protocol (Protocal) can separate the definition of methods in the business to form a separate file, this is consistent with the extraction interface in traditional OO. If two systems need to exchange data, you can develop a protocal that both parties comply with, and then add the protocol file to the project in both systems to implement it. This function is not available in informal protocols (@ interface. (If you do not believe this, you can change IQUERY in nsobject <IQUERY> to the interface definition name of other classes. Compilation is not successful.) In addition, some extensions are made to the official protocol in obj-C 2.0, the methods in the formal protocol can be identified as "required (@ requied)" and "optional (@ optional)". If the methods in the Protocol are identified as @ optional, even if the classes using this Protocol do not implement these methods, the compiler will not give a warning. This gives formal agreements more flexibility. Example:
@protocol IQuery@required-(void) Query:(NSString*) sql;@optional-(void) HelloWorld; @end
With the @ optional keyword, "informal protocols" can be replaced by "formal protocols" in terms of semantics, in fact, informal protocols in cocoa are gradually replaced by formal protocols marked with @ optional.
If you select nsobject in xcode code and right-click --> jump to definition, you will find that nsobject is actually an interface or protocal.
Select protocal nsobject to continue. The nsobject. h file defines protocal nsobject.
Similarly, you can also see the definition of interface nsobject.
From this point, we can see that the interface nsobject of the informal protocol actually uses the formal protocol protocal nsobject.
That is to say, in the OO world of obj-C, nsobject, the ancestor of all things, is actually a "formal protocol", so all classes derived from nsobject, only one or more protocols are observed.
Another topic generic
In obj-C, everything is a pointer. In the previous study, we have come into contact with a special type ID, which can be considered as a special pointer: it can point to any type of object. ID, coupled with the formal protocol, can achieve the effect of the C # Generic Type (Note: It is just like it, not like it)
#import <Foundation/Foundation.h>#import "IQuery.h"@interface DBQuery : NSObject<IQuery> {}-(void) test:(id<IQuery>) obj;@end
Note that-(void) test :( id <IQUERY>) OBJ; this indicates that the test method accepts an object of any type as a parameter, but this parameter object must be implementedProtocolIQUERY (it can also be said that this parameter object must use the formal protocol IQUERY). Is it similar to void test (list <IQUERY> OBJ) in C?
Author: Yang Guo under the bodhi tree
Source: http://yjmyzz.cnblogs.com but in obj-c There are two concepts close to it: "Informal protocol" and "formal protocol )". Although the keyword of the informal protocol in obj-C is also interface, this is not exactly the same as the interface in C. Recall what we have learned before. When we define a sample class, we always convert it into a sample. h. The Code is as follows:
#import <Foundation/Foundation.h>@interface Sample : NSObject {}-(void) HelloWorld;@end
It indicates that there is a method named helloworld in the sample class that stipulates "should" (Note: what I am talking about here is yes, not a must). It is just a gentleman agreement.
If we do not comply with this convention in sample. m (that is, do not implement this method), xcode will give a warning during compilation, as shown in. But it will still be compiled successfully at the end (that is, the compiler closes one eye with one eye, which defaults to this kind of cheating behavior of the sample class)
Note: incomplete implementation of Class "sample". Meaning: The sample class does not fully implement the methods agreed in interface. This is where the protocol in obj-C is different from the interface in C #: the interface in C # is mandatory and must be implemented; otherwise, compilation will fail, while obj-C will warn during compilation, it can finally be compiled. The formal protocol (Protocal) is actually an informal protocol (interface). It looks more formal and more semantic: classes that require the protocol, "must" implement the methods agreed in the Protocol. However, it is entertaining that, even if it is known as a formal protocol, the compiler still gives a warning when it encounters noncompliance during compilation. (Of course, the formal protocol also has its meaning, which will be mentioned later) Here we define an IQUERY protocol IQUERY. h.
@protocol IQuery-(void) Query:(NSString*) sql;@end
In addition to changing the keyword @ interface to @ protocal, the others are basically unchanged. The following defines a class dbquery and uses this formal protocol dbquery. h
#import <Foundation/Foundation.h>#import "IQuery.h"@interface DBQuery : NSObject<IQuery> {}@end
Note that dbquery: nsobject <IQUERY> indicates that dbquery inherits from nsobject.
ProtocolIQUERY. Dbquery. m
#import "DBQuery.h"@implementation DBQuery-(void) Query:(NSString *)sql{NSLog(@"Query is called. sql:%@",sql);}@end
Of course, if you do not implement the method query in dbquery. M, you can compile and pass the query, but you will receive a warning. So far, you may think that protocal and interface are similar concepts. protocal design is purely redundant. In fact, protocal has an important significance: the formal protocol (Protocal) can separate the definition of methods in the business to form a separate file, this is consistent with the extraction interface in traditional OO. If two systems need to exchange data, you can develop a protocal that both parties comply with, and then add the protocol file to the project in both systems to implement it. This function is not available in informal protocols (@ interface. (If you do not believe this, you can change IQUERY in nsobject <IQUERY> to the interface definition name of other classes. Compilation is not successful.) In addition, some extensions are made to the official protocol in obj-C 2.0, the methods in the formal protocol can be identified as "required (@ requied)" and "optional (@ optional)". If the methods in the Protocol are identified as @ optional, even if the classes using this Protocol do not implement these methods, the compiler will not give a warning. This gives formal agreements more flexibility. Example:
@protocol IQuery@required-(void) Query:(NSString*) sql;@optional-(void) HelloWorld; @end
With the @ optional keyword, "informal protocols" can be replaced by "formal protocols" in terms of semantics, in fact, informal protocols in cocoa are gradually replaced by formal protocols marked with @ optional.
If you select nsobject in xcode code and right-click --> jump to definition, you will find that nsobject is actually an interface or protocal.
Select protocal nsobject to continue. The nsobject. h file defines protocal nsobject.
Similarly, you can also see the definition of interface nsobject.
From this point, we can see that the interface nsobject of the informal protocol actually uses the formal protocol protocal nsobject.
That is to say, in the OO world of obj-C, nsobject, the ancestor of all things, is actually a "formal protocol", so all classes derived from nsobject, only one or more protocols are observed.
Another topic generic
In obj-C, everything is a pointer. In the previous study, we have come into contact with a special type ID, which can be considered as a special pointer: it can point to any type of object. ID, coupled with the formal protocol, can achieve the effect of the C # Generic Type (Note: It is just like it, not like it)
#import <Foundation/Foundation.h>#import "IQuery.h"@interface DBQuery : NSObject<IQuery> {}-(void) test:(id<IQuery>) obj;@end
Note that-(void) test :( id <IQUERY>) OBJ; this indicates that the test method accepts an object of any type as a parameter, but this parameter object must be implementedProtocolIQUERY (it can also be said that this parameter object must use the formal protocol IQUERY). Is it similar to void test (list <IQUERY> OBJ) in C?