Chapter 52 API and API design notes and api52 notes

Chapter 52 API and API design notes and api52 notes

Chapter 52 API and API design notes

Article 15th: Use a prefix to avoid namespace conflicts

Objective-C does not have the built-in namespace mechanism in other languages. In view of this, we should try to avoid potential naming conflicts when naming, otherwise it will be easy to rename again. If a name conflict occurs with naming clash, the connection process of the application will fail.

The only way to avoid this problem is to implement namespaces in disguise: Add appropriate prefixes to all names.

 

Article 3: provides an all-around Initialization Method

You can specify the Initialization Method designated initialier for the initialization method that can provide necessary information for the object so that it can complete the work.

If there are more than one method to create an instance, this class will have multiple initialization methods. However, you must select one of them as the designated initializer, so that other initialization methods can call it.

Among the above initialization methods, initWithTimeIntervalSinceReferenceDate: it is designated initializer.

 

Article 3: communication between objects through delegated and Data Source protocols

The purpose of this mode is to define a set of interfaces. If an object wants to accept another object's delegate, it must follow this interface to become its delegate object delegate. the other object can return some information to the delegate object, or notify the delegate object in the event of a related event.

 

This mode is generally implemented through the Protocol language feature. The entire Cocoa system framework does this.

Article 12: scatter the implementation code of classes into several categories that are easy to manage

Classes often fill up various methods, and the code of these methods is all heap in a huge implementation file.

Through the Objective-C classification mechanism, class code is logically divided into several partitions, which is good for development and debugging.

 

Model personal information as a class.

You can use the classification mechanism to rewrite the class as follows:

The class implementation code is divided into several parts by method. Therefore, this language feature is certainly called classification.

After the classification mechanism is used, you can still define the entire class in an interface file and write its code in an implementation file. However, as the number of categories increases, the current implementation file will soon expand. In this case, each category can be extracted to its own files.

Taking EOCPerson as an example, you can classify it into the following files:

Through the classification mechanism, you can divide the class code into many small pieces that are easy to manage for separate inspection. If you want to use the classification method after using the classification mechanism, remember to introduce the classification header file when introducing EOCPerson. h.

Although a little troublesome, classification is still a good way to manage code.

25th: always add a prefix to the category name of a third party.

Article 3: do not declare attributes in categories

Attribute is the way to encapsulate data. Although technically speaking, classification can also declare attributes, this approach should be avoided as much as possible.

The Correlated object can solve the problem that instance variables cannot be merged in classification.

This is feasible, but not ideal. Similar code should be written many times, and it is prone to errors in memory management, because we often forget to follow the memory management semantics when implementing access methods for attributes.

Although this method is not bad, I do not recommend it.

Defining an attribute in a main interface is much easier than cleaning the definition in a category.

As for the classification mechanism, it should be understood as a means with the goal of extending the functions of the class.

Sometimes the read-only attribute can still be used in the category.

Because obtaining methods does not access data, and attributes do not need to be implemented by instance variables, You can implement classification as follows:

Article 27th: Hide implementation details using class-continuation Classification

Article 3: provision of anonymous objects through protocols

The Protocol defines a series of methods that the object following the Protocol should implement. As a result, we can use the Protocol to hide the implementation details of the API only, and design the returned object as a pure id type that complies with this Protocol.

When defining the delegate attribute, you can write

@ Property (nonatomic, weak) id <EOCDelegate> delegate;

Because the type of this attribute is id <EOCDelegate>, in fact, any class object can act as this attribute, even if the class does not inherit from NSObject, it can only follow the EOCDelegat protocol.