iOS Development Note Series-Basic 5 (Classification and Protocol)

Classification

In Objective-c, in addition to adding new methods to classes by creating new subclasses, you can also categorize them. Classification provides a simple way to modularize the definition of a class into a group or class of related methods, and it provides an easy way to extend the definition of an existing class without having to access the source code of the class or create subclasses.

Like what:

// Someclass+mathops.h #import " SomeClass.h " @interface SomeClass (Mathops)-(SomeClass *) Add: (SomeClass *) s; -(SomeClass *) Sub: (SomeClass *) s; -(SomeClass *) div: (SomeClass *) s; -(SomeClass *) Mul: (SomeClass *) s; @end

There is no need to list the parent class, nor to tell the compiler about the instance variable, since this is already done from the interface section of the import file.

You can place the definition of all methods in an implementation section. That is, you can define all the methods in the SomeClass.h interface section in one implementation file, and all the methods in the Mathops classification. Alternatively, define the classification methods in separate implementations, in which case the implementation part of these methods must identify the classification to which the method belongs. such as @implementation SomeClass (mathops).

If the classification is placed in a main class definition file, all users of this class will access the methods in this classification. If you cannot directly modify the original header file, you can only save the file separately from the taxonomy.

Extension of the class

　　Creating an unnamed category and not specifying a name within () is a special case where the special syntax is defined as an extension of the class. When defining an unnamed taxonomy like this, you can extend the class by defining additional instance variables, which are not allowed in the named taxonomy. The methods declared in an unnamed taxonomy need to be implemented in the main implementation area, rather than in the decoupled implementation area. If you do not implement all of the methods listed in the interface section of an unnamed taxonomy, the compiler warns you.

For example, in the implementation file for a class:

//SOMECLASS.M#import "SomeClass.h"//extension of the class@interfaceSomeClass () @propertyintpp;-(void) SomeFunc;@end//--------------------------@implementationSomeClass@synthesizepp; ..@end

This class is extended by adding a new instance variable and method, and the access method is synthesized.

Unnamed classifications are useful because their methods are private. If you need to write a class whose data and methods are used only by the class itself, the unnamed classification is more appropriate.

Considerations for classification:

Classification can overwrite another method in the class, but this is a poor design, because after a method is covered, the original method cannot be accessed. If overwrite is required, the correct choice is to create a subclass that overrides the method of the parent class, and the parent class's original method can still be called by Super.

You can have many classifications, and if a method is defined in more than one taxonomy, the statement does not specify which classification to use.

Adding a new method by classification will not only affect the class, but will also affect all of its subclasses.

Agreement

　　A protocol is a list of methods that are shared by multiple classes, and the methods listed in the protocol do not have a corresponding implementation and are intended to be implemented by others. The protocol provides a way to define a set of somewhat related methods with the specified name. Some of these methods have to be implemented (@required), and some are optional (@optional).

The definition protocol is to use the @protocol directive, followed by the protocol name.

When a protocol is adopted, the protocol name can be listed in the last pair of <> in the @interface line, and at least the implementation of the Protocol must be implemented at the realization part.

For example: @interface someclass:superclass <SomeProtocol>

The protocol is non-class, it does not reference any class, and any class can abide by a protocol. You can use the Comformstoprotocol: method to check whether an object follows a protocol.

Agent

The protocol is also an interface definition between two classes. Classes that define protocols can be seen as proxies to the methods that implement them, so that the definition of a class can be more generic because the action is assumed by the proxy class to respond to certain events or to define certain parameters. Cocoa and iOS rely heavily on the concept of proxies. such as the UITableView class, this class does not know what the title of the table is, how many chunks to include or how many rows to fill, and what the contents of the table are. So, the proxy defines a uitableviewdatasource protocol, and if it needs information, such as how many rows per chunk in a table, it calls the method that implements the protocol in the class. The UITableView class also defines other protocols such as Uitableviewdelegate, which also defines methods such as what is required for a row in a table, UITableView does not know what to do, so the delegate is given to the actual user.

Informal agreements

An informal protocol is actually a classification that lists a set of methods but does not implement them. Everyone inherits the same root object, so informal protocols are usually defined for the root class. Sometimes, informal agreements are also called abstract protocols. Because the informal protocol itself is not a protocol but a classification, the compiler does not provide protocol-related help, and there is no concept of compliance or non-compliance with informal protocols or by compiler testing.

Composition Object

In addition to extending the class definition by deriving subclasses and classifications, there is also a technique that defines a class that contains one or more objects of another class, and the object of the new class is the composition object, because it is made up of other objects.

By extending the parent class with derived subclasses, the subclass integrates all of the instance variables and methods of the parent class, and in some cases, some methods do not apply to subclasses, but users of subclasses may access them. As an alternative to creating subclasses, you can define a new class that contains an instance variable to extend the class, and then simply define a method in the new class that is appropriate for the class. Like what:

@interface newclass:nsobject{  *s;  } -(void) newfunc; @end

It is important to note that, unlike the subclass extension, the subclass version allows direct access to the parent class's method, where the Newclass object cannot directly access the SomeClass method, but in its own method such as Newfunc, through instance variable s to access the methods that can be used. Remember, here at initialization, you need to overwrite the init or custom initialization method to allocate space for S.

iOS Development Note Series-Basic 5 (Classification and Protocol)