Zen and the Art of Objective-C Programming: Exploring Zen Cultivation from Writing Details

Zen and the Art of Objective-C Programming: Exploring Zen Cultivation from Writing Details

[[140326]]

Preface

We started writing this book in November 2013, with the initial goal of providing a guide to writing clean and beautiful Objective-C code: there are many guides out there, but they all have some problems. We didn't want to introduce some rigid rules, we wanted to provide a way to write more consistent code between developers. Over time, the book began to shift to explaining how to design and build good code.

The idea of ​​this book is that code should not only compile, but also "work". Good code has several characteristics: concise, self-explanatory, well organized, well documented, well named, well designed, and proven. One of the principles of this book is to prioritize clarity over performance, and explain why this should be done. Although all the code is written in Objective-C, some themes are universal and independent of programming language.

Swift

On June 6, 2014, Apple released a new language for iOS and Mac development: Swift. This new language is very different from Objective-C. As a result, we changed our plans for this book. We decided to publish the book in its current state, rather than continue writing about the topic we had originally planned. Objective-C is not going away, but it is not a wise choice to continue writing this book in a language that is slowly losing attention.

Contribute to the community

We released this book for free and contributed it to the community because we wanted to provide readers with something valuable. If you can learn at least one best practice, we will have achieved our goal.

We have carefully polished the text, but there may still be some spelling or other errors. We would very much like readers to give us feedback or suggestions to improve the book. So if you have any questions, please contact us. We welcome all kinds of pull-requests.

Conditional Statements

To avoid errors, the body of a conditional statement should always be surrounded by curly braces, even if it is not necessary (for example, the conditional body is a single line). Possible errors are: adding a second line and mistaking it for the body of the if statement. Moreover, and more dangerously, if a line in the body of an if statement is commented out, the next line of code will become the code of the if statement.

recommend:

  1.  if (!error) {
  2.  return success;
  3.  }

Not recommended:

  1.  if (!error)
  2.  return success;

or

  1.  if (!error) return success;

The famous goto fail bug was discovered in Apple's SSL/TLS implementation in February 2014.

The code is here:

  1.  static OSStatus
  2.  SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
  3.                                  uint8_t *signature, UInt16 signatureLen)
  4.  {
  5.  OSStatus err;
  6.  ... 
  7.  
  8.  if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0 )
  9.  goto fail;
  10.  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0 )
  11.  goto fail;
  12.  goto fail;
  13.  if ((err = SSLHashSHA1. final (&hashCtx, &hashOut)) != 0 )
  14.  goto fail;
  15.  ... 
  16.  
  17.  fail:
  18.   SSLFreeBuffer(&signedHashes);
  19.  SSLFreeBuffer(&hashCtx);
  20.  return err;
  21.  }

Obviously, there are two consecutive goto fail; lines without brackets. We certainly don't want to write the above code and cause errors.

In addition, other conditional statements should also be unified in this style, which makes it easier to check.

Yoda Expressions

Don't use Yoda expressions. Yoda expressions are when you compare a constant to a variable instead of comparing a variable to a constant. It's like saying "Is blue the color of the sky" or "Is tall a property of a man" instead of "Is the sky blue" or "Is this man tall"

[[140325]]

(Translator's note: The name originated from the way Master Yoda speaks in Star Wars, which always uses inverted word order)

recommend:

  1.  if ([myValue isEqual: @42 ]) { ...

Not recommended:

  1.  if ([ @42 isEqual:myValue]) { ...

nil and BOOL checks

Similar to Yoda expressions, the way nil checks are done is controversial. Some notous libraries check if an object is nil like this:

  1.  if (nil == myValue) { ...

Some people may argue that this is wrong, because in the case of nil as a constant, it is like a Yoda expression. But some programmers do this to avoid debugging difficulties. Look at the following code:

  1.  if (myValue == nil) { ...

If the programmer types this mistake:

  1.  if (myValue = nil) { ...

This is a legal statement, but even if you are an experienced programmer, it is difficult to debug the error even if you stare at it many times. However, if nil is placed on the left, since it cannot be assigned a value, such an error will not occur. If the programmer does this, he/she can easily check the possible cause, which is much better than checking the typed code again and again.

To avoid these strange problems, you can use the exclamation mark as an operator. Because nil is interpreted as NO, there is no need to compare it with other values ​​in the conditional statement. Also, do not compare it directly with YES, because YES is defined as 1, and BOOL is 8 bits, which is actually a char type.

recommend:

  1.  if (someObject) { ...
  2.  if (![someObject boolValue]) { ...
  3.  if (!someObject) { ...

Not recommended:

  1.  if (someObject == YES) { ... // Wrong  
  2.  if (myRawValue == YES) { ... // Never do this.  
  3.  if ([someObject boolValue] == NO) { ...

This will also improve consistency and increase readability.

Golden Mile

When writing conditional statements, the left code spacing should be a "golden" or "happy" path. That is, don't nest if statements. Multiple return statements are OK. This avoids cyclomatic complexity and makes the code easier to read. Because the important parts of your method are not nested on branches, you can clearly find the relevant code.

recommend:

  1.  - ( void )someMethod {
  2.  if (![someOther boolValue]) {
  3.  return ;
  4.  } 
  5.  
  6.  //Do something important  
  7.  }

Not recommended:

  1.  - ( void )someMethod {
  2.  if ([someOther boolValue]) {
  3.  //Do something important  
  4.  }
  5.  }

#p#

Complex expressions

When you have a complex if clause, you should extract them and assign them to a BOOL variable, which can make the logic clearer and make the meaning of each clause clear.

  1.  BOOL nameContainsSwift = [sessionName containsString:@ "Swift" ];
  2.  BOOL isCurrentYear = [sessionDateComponents year] == 2014 ;
  3.  BOOL isSwiftSession = nameContainsSwift && isCurrentYear; 
  4.  
  5.  if (isSwiftSession) {
  6.  // Do something very cool  
  7.  }

Ternary Operator

The ternary operator? should only be used where it makes the code clearer. All variables in a conditional statement should be evaluated. Similar to if statements, evaluating multiple conditional clauses usually makes the statement more difficult to understand. Alternatively, they can be refactored into instance variables.

recommend:

  1.  result = a > b ? x : y;

Not recommended:

  1.  result = a > b ? x = c > d ? c : d : y;

When the second argument of the ternary operator (the if branch) returns the same object as the one already checked in the conditional, the following expression is more clever:

recommend:

  1.  result = object ? : [self createObject];

Not recommended:

  1.  result = object ? object : [self createObject];

Error handling

When a method returns a reference to an error parameter, check the return value, not the error variable.

recommend:

  1.  NSError *error = nil;
  2.  if (![self trySomethingWithError:&error]) {
  3.  // Handle Error  
  4.  }

Furthermore, some Apple APIs write garbage values ​​to the error parameter (if it is non-NULL) on success, so checking the error value may result in errors (or even crashes).

Case Statement

Unless the compiler requires it, parentheses are not necessary in case statements. However, when a case contains multiple lines of statements, parentheses are required.

  1.  switch (condition) {
  2.  case   1 :
  3.  // ...  
  4.  break ;
  5.  case   2 : {
  6.  // ...  
  7.  // Multi-line example using braces  
  8.  break ;
  9.  }
  10.  case   3 :
  11.  // ...  
  12.  break ;
  13.  default :
  14.  // ...  
  15.  break ;
  16.  }

Sometimes you can use fall-through to execute the same code in different cases. A fall-through removes the "break" of a case statement and allows the following case to continue executing.

  1.  switch (condition) {
  2.  case   1 :
  3.  case   2 :
  4.  //code executed for values ​​1 and 2  
  5.  break ;
  6.  default :
  7.  // ...  
  8.  break ;
  9.  }

When using an enumerable variable in a switch statement, default is unnecessary. For example:

  1.  switch (menuType) {
  2.  case ZOCEnumNone:
  3.  // ...  
  4.  break ;
  5.  case ZOCEnumValue1:
  6.  // ...  
  7.  break ;
  8.  case ZOCEnumValue2:
  9.  // ...  
  10.  break ;
  11.  }

In addition, to avoid using the default case, if a new value is added to the enum, the programmer will immediately receive a warning notification

Enumeration value 'ZOCEnumValue3' not handled in switch.

Enumeration Types

When using enum, it is recommended to use the new fixed base type definition, which has more powerful type checking and code completion. The SDK now has a macro to encourage and promote the use of fixed type definitions - NS_ENUM()

*example: *

  1.  typedef NS_ENUM(NSUInteger, ZOCMachineState) {
  2.  ZOCMachineStateNone,
  3.  ZOCMachineStateIdle,
  4.  ZOCMachineStateRunning,
  5.  ZOCMachineStatePaused
  6.  };

name

General Conventions

Follow Apple naming conventions whenever possible, especially with regard to Memory Management Rules (NARC).

Prefer long, descriptive method and variable names

recommend:

  1.  UIButton *settingsButton;

Not recommended:

  1.  UIButton *setBut;

#p#

constant

Constants SHOULD use CamelCase and SHOULD be prefixed with the relevant class name for clarity.

recommend:

  1.  static   const NSTimeInterval ZOCSignInViewControllerFadeOutAnimationDuration = 0.4 ;

Not recommended:

  1.  static   const NSTimeInterval fadeOutTime = 0.4 ;

Constants should use in-line string literals or numbers as much as possible, so that they can be reused frequently and modified quickly without searching and replacing. Constants should be declared with static, and do not use #define unless it is explicitly used as a macro.

recommend:

  1.  static NSString * const ZOCCacheControllerDidClearCacheNotification = @ "ZOCCacheControllerDidClearCacheNotification" ;
  2.  static   const CGFloat ZOCImageThumbnailHeight = 50 .0f;

Not recommended:

  1.  #define CompanyName @ "Apple Inc."  
  2.  #define magicNumber 42  

Constants should be declared in the interface file like this:

  1.  extern NSString * const ZOCCacheControllerDidClearCacheNotification;

And its definition should be implemented in the implementation file.

You only need to add the namespace prefix to public constants. Even though private constants may be used in different patterns in implementation files, you don't need to stick to this rule.

method

For method signatures, there should be a space after the method type (-/+ signs). There should also be a space between method sections (to comply with Apple's conventions). There should always be a descriptive keyword before the parameter name.

Be more careful when using the "and" notation. It should not be used to indicate that there are multiple parameters, such as in the following initWithWidth:height: example:

recommend:

  1.  - ( void )setExampleText:(NSString *)text image:(UIImage *)image;
  2.  - ( void )sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag;
  3.  - (id)viewWithTag:(NSInteger)tag;
  4.  - (instancetype)initWithWidth:(CGFloat)width height:(CGFloat)height;

Not recommended:

  1.  - ( void )setT:(NSString *)text i:(UIImage *)image;
  2.  - ( void )sendAction:(SEL)aSelector:(id)anObject:(BOOL)flag;
  3.  - (id)taggedView:(NSInteger)tag;
  4.  - (instancetype)initWithWidth:(CGFloat)width andHeight:(CGFloat)height;
  5.  - (instancetype)initWith:( int )width and:( int )height; // Never do this.  

Literals

NSString, NSDictionary, NSArray, and NSNumber literals should be used whenever you create immutable instances of an object. Be especially careful not to put nil into NSArray and NSDictionary, as this will cause crashes.

example:

  1.  NSArray *names = @[@ "Brian" , @ "Matt" , @ "Chris" , @ "Alex" , @ "Steve" , @ "Paul" ];
  2.  NSDictionary *productManagers = @{@ "iPhone" : @ "Kate" , @ "iPad" : @ "Kamal" , @ "Mobile Web" : @ "Bill" };
  3.  NSNumber *shouldUseLiterals = @YES ;
  4.  NSNumber *buildingZIPCode = @10018 ;

Don’t do this:

  1.  NSArray *names = [NSArray arrayWithObjects:@ "Brian" , @ "Matt" , @ "Chris" , @ "Alex" , @ "Steve" , @ "Paul" , nil];
  2.  NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @ "Kate" , @ "iPhone" , @ "Kamal" , @ "iPad" , @ "Bill" , @ "Mobile Web" , nil];
  3.  NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];
  4.  NSNumber *buildingZIPCode = [NSNumber numberWithInteger: 10018 ];

For mutable copies, we recommend using explicit classes such as NSMutableArray and NSMutableString.

The following examples should be avoided:

  1.  NSMutableArray *aMutableArray = [@[] mutableCopy];

The above writing method has problems with efficiency and readability. In terms of efficiency, an unnecessary immutable variable is created and immediately discarded; this will not make your app slower (unless this method is called very frequently), but it is indeed unnecessary to do so just to save a few words. For readability, there are two problems: the first is that when browsing the code and seeing @[] your mind will immediately associate it with an instance of NSArray, but in this case you need to stop and think. On the other hand, some newcomers may feel uncomfortable with the distinction between mutable and immutable objects after seeing it. He/she may not be very familiar with creating a copy of a mutable object (of course this does not mean that this knowledge is not important). Of course, this does not mean that there is an absolute error, but there are some problems with usability (including readability).

kind

Class Name

Class names should be prefixed with three uppercase letters (two letters are reserved for Apple classes). Although this convention looks ugly, it can reduce the problems caused by the lack of namespaces in objective-c.

Some developers do not follow this convention when defining Model objects (for Core Data objects, we should follow this convention even more). We recommend strictly following this convention when defining Core Data objects, because you may end up merging your Managed Object Model into other (third-party library) Managed Object Models.

You may have noticed that the prefix of the classes in this book (actually not just classes) is ZOC.

Another class naming convention: When you create a subclass, you should put the descriptive part between the prefix and the superclass name. For example: if you have a ZOCNetworkClient class, the subclass name would be ZOCTwitterNetworkClient (note that "Twitter" is between "ZOC" and "NetworkClient"); following this convention, a UIViewController subclass would be ZOCTimelineViewController.

Initializer and dealloc

Recommended code organization: Place the dealloc method at the beginning of the implementation file (directly after @synthesize and @dynamic), and init should be placed after dealloc. If there are multiple initializers, the designated initializer should be placed first, and the secondary initializer should follow immediately after, which is more logical. Today with ARC, the dealloc method rarely needs to be implemented, but putting init and dealloc together can visually emphasize that they are a pair. Usually, what you do in the init method needs to be undone in the dealloc method.

The init method should have the following structure:

  1.  - (instancetype)init
  2.  {
  3.     self = [ super init]; // call the designated initializer  
  4.  if (self) {
  5.  // Custom initialization  
  6.  }
  7.  return self;
  8.  }

Why is self set to the return value of [super init] and what happens in between? This is a very interesting topic.

Let's take a step back: We've been writing expressions like [[NSObject alloc] init] , blurring the distinction between alloc and init . An Objective-C feature is called two-step creation . This means that allocating memory and initializing it are two separate operations.

  • alloc means allocating memory for an object, which involves allocating enough available memory to save the object, writing the isa pointer, initializing the retain count, and initializing all instance variables.
  • init stands for initializing an object, which means converting the object to a usable state. This usually means assigning usable values ​​to the object's instance variables.

The alloc method returns a valid uninitialized instance object. Each message sent to the instance is translated into a call to the objc_msgSend() function with a pointer to the object returned by alloc and named self. After that, self is ready to execute all methods. To complete the two-step creation, the first method sent to the newly created instance should be the conventional init method. Note that in the init implementation of NSObject, only self is returned.

There is one other important contract about init: this method can (and should) return nil if it cannot successfully complete initialization; initialization can fail for a variety of reasons, such as a malformed input, or failure to successfully initialize a required object. This explains why you should always call self = [super init]. If your superclass does not successfully initialize itself, you must assume that you are in a paradoxical state and do not handle your own initialization logic in your implementation and return nil. If you do not do this, you will end up with an unusable object whose behavior is unpredictable and may eventually crash your app.

Reassigning self can also be used by init to return different instances when called. An example is a class cluster or other Cocoa class that returns the same (immutable) instance object.

#p#

Designated and Secondary Initializers

Objective-C has the concept of designated and secondary initializers. A designated initializer is one that provides all the parameters, and a secondary initializer is one or more initializers that call the designated initializer with one or more default parameters.

  1.  @implementation ZOCEvent 
  2.  
  3.  - (instancetype)initWithTitle:(NSString *)title
  4.                          date:(NSDate *)date
  5.                      location:(CLLocation *)location
  6.  {
  7.  self = [ super init];
  8.  if (self) {
  9.  _title = title;
  10.  _date = date;
  11.  _location = location;
  12.  }
  13.  return self;
  14.  } 
  15.  
  16.  - (instancetype)initWithTitle:(NSString *)title
  17.                          date:(NSDate *)date
  18.  {
  19.  return [self initWithTitle:title date:date location:nil];
  20.  } 
  21.  
  22.  - (instancetype)initWithTitle:(NSString *)title
  23.  {
  24.  return [self initWithTitle:title date:[NSDate date] location:nil];
  25.  } 
  26.  
  27.  @end  

initWithTitle:date:location: is the designated initialization method, and the other two are secondary initialization methods. Because they just call the designated initialization method implemented by the class

Designated Initializer

A class should have only one designated initialization method, and other initialization methods should call this designated initialization method (although there is an exception to this situation)

This divergence does not require that initialization function be called.

It is legal to call any designated initializer method in a class hierarchy, and you should ensure that all designated initializers are called in the class hierarchy from the ancestor (usually NSObject) down to your class. In practice this means that the first initializer code executed is the furthest ancestor, and then from the top down, all classes have a chance to execute their specific initializer code. This way, anything you inherit from a superclass is disabled before you do your specific initialization work. Even if its status is unclear, all Apple Frameworks are guaranteed to follow this convention, and your class should do the same.

There are three different ways when defining a new class:

  • No need to overload any initialization functions
  • Overloading designated initializers
  • Define a new designated initializer

The first approach is the simplest: you don't need to add any initialization logic to your class, just follow the superclass's designated initializer. You can override a designated initializer when you want to provide additional initialization logic. You only need to override the designated initializer of your immediate superclass and make sure your implementation calls the superclass's method. A typical example is when you override the initWithNibName:bundle: method when you create a UIViewController subclass.

  1.  @implementation ZOCViewController 
  2.  
  3.  - (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
  4.  {
  5.  // call to the superclass designated initializer  
  6.     self = [ super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
  7.  if (self) {
  8.  // Custom initialization  
  9.  }
  10.  return self;
  11.  } 
  12.  
  13.  @end  

In the case of a UIViewController subclass, it would be an error to override init , in which case the caller will try to call initWithNib:bundle to initialize your class, and your class implementation will not be called. This also violates the rule that it should be legal to call any designated initializer.

When you wish to provide your own initialization function, you should follow these three steps to ensure correctness:

  • Define your designated initializer, making sure to call the designated initializer of the immediate superclass.
  • Override the designated initializer of the direct superclass. Call your new designated initializer.
  • Document new designated initializers.

Many developers ignore the last two steps, which is not only a matter of carelessness, but also a violation of the rules of the framework and may lead to undefined behavior and bugs. Let's look at an example of correct implementation:

  1.  @implementation ZOCNewsViewController 
  2.  
  3.  - (id)initWithNews:(ZOCNews *)news
  4.  {
  5.  // call to the immediate superclass's designated initializer  
  6.     self = [ super initWithNibName:nil bundle:nil];
  7.  if (self) {
  8.  _news = news;
  9.  }
  10.  return self;
  11.  } 
  12.  
  13.  // Override the immediate superclass's designated initializer  
  14.  - (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
  15.  {
  16.  // call the new designated initializer  
  17.  return [self initWithNews:nil];
  18.  } 
  19.  
  20.  @end  

If you don't override initWithNibName:bundle: and the caller decides to use this method to initialize your class (which is perfectly legal), initWithNews: will never be called, resulting in incorrect initialization flow and your class-specific initialization logic will not be executed.

Even if you can infer which method is the designated initializer, it is better to make it clear (future you or other developers will thank you when they modify your code). You should consider using two strategies (which are not mutually exclusive): The first is to make it clear in the documentation which initializers are designated. You can use the compiler directive __attribute__((objc_designated_initializer)) to mark your intention. When using this compiler directive, the compiler will help you. If your new designated initializer does not call your superclass's designated initializer, the compiler will issue a warning. However, when the designated initializer of the class is not called (and in turn provides the necessary parameters), calling the designated initializer in other superclasses will become an unusable state. Referring to the previous example, it would be meaningless to instantiate a ZOCNewsViewController to display a news item if the news item is not displayed. In this case, you should only disable other designated initializers to force calling a very specific designated initializer. By decorating a method with another compiler directive __attribute__((unavailable("Invoke the designated initializer"))) , you will get a compilation error when you try to call the method with this attribute.

This is the header file for the previous example (macro is used here to make the code less verbose)

  1.  @interface ZOCNewsViewController : UIViewController 
  2.  
  3.  - (instancetype)initWithNews:(ZOCNews *)news ZOC_DESIGNATED_INITIALIZER;
  4.  - (instancetype)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil ZOC_UNAVAILABLE_INSTEAD(initWithNews:);
  5.  - (instancetype)init ZOC_UNAVAILABLE_INSTEAD(initWithNews:); 
  6.  
  7.  @end  

A corollary of the above is that you should never call a secondary initializer from a designated initializer (if the secondary initializer follows the contract, it will call the designated initializer). If you do this, the call is likely to call an init method overridden by a subclass and fall into infinite recursion.

However, one exception is if an object conforms to the NSCoding protocol and it is initialized through the method initWithCoder:. We should treat it differently depending on whether the superclass conforms to the NSCoding protocol. If it does, if you just call [super initWithCoder:], you may have a shared initialization code in the designated initializer. A good approach is to put this code in a private method (such as p_commonInit). When your superclass does not conform to the NSCoding protocol, it is recommended to treat initWithCoder: as a secondary initializer and call self's designated initializer. Note that this is a violation of Apple's Archives and Serializations Programming Guide:

the object should first invoke its superclass's designated initializer to initialize inherited state

If your class is not a direct subclass of NSObject, doing so can result in unpredictable behavior.

Secondary Initializer

As described before, secondary initializer is a convenient way to provide default values ​​and behaviors to designated initializer. That is, you should not force many initialization operations in such a method, and you should always assume that this method will not be called. We guarantee that the only method called is the designated initializer. This means that your designated initializer should always call other secondary initializers or your designated initializer of self. Sometimes, due to mistakes, super may be typed, which will lead to failure to comply with the initialization order mentioned above (in this particular case, the initialization of the current class is skipped)

refer to
  • https://developer.apple.com/library/ios/Documentation/General/Conceptual/DevPedia-CocoaCore/ObjectCreation.html
  • https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaEncyclopedia/Initialization/Initialization.html
  • https://developer.apple.com/library/ios/Documentation/General/Conceptual/DevPedia-CocoaCore/MultipleInitializers.html
  • https://blog.twitter.com/2014/how-to-objective-c-initializer-patterns

instancetype

We often overlook that Cocoa is full of conventions, and these conventions help the compiler be smarter. Whenever the compiler encounters an alloc or init method, it knows that even though the return type is id, these methods always return an instance of the class type they receive. Therefore, it allows the compiler to do type checking. (For example, check whether the type returned by the method is legal). Clang benefits from this related result type, which means:

messages sent to one of alloc and init methods will have the same static type as the instance of the receiver class.

For more information on this convention of automatically defining relevant return types, see the appropriate section of the Clang Language Extensions guide.

A relative return type can be explicitly specified using the instancetype keyword as the return type, and it can be useful in some factory method or constructor method scenarios. It can hint the compiler to check the type correctly, and more importantly, this also applies to its subclasses.

  1.  @interface ZOCPerson
  2.  + (instancetype)personWithName:(NSString *)name;
  3.  @end  

However, according to clang's definition, id can be promoted to instancetype by the compiler. We strongly recommend using instancetype for all class methods and instance methods that return instances of the class, such as in alloc or init.

Form habits and be consistent in your API. Moreover, by making small adjustments to your code you can improve readability: at a glance you can distinguish which methods return instances of your class. You will thank yourself for paying attention to these small details later.

refer to
  • http://tewha.net/2013/02/why-you-should-use-instancetype-instead-of-id/
  • http://tewha.net/2013/01/when-is-id-promoted-to-instancetype/
  • http://clang.llvm.org/docs/LanguageExtensions.html#related-result-types
  • http://nshipster.com/instancetype/

#p#

Initialization Mode

Class cluster

Class clusters are described in Apple's documentation as follows:

an architecture that groups a number of private, concrete subclasses under a public, abstract superclass.

If this description sounds familiar, your intuition is correct. Class cluster is Apple's name for the abstract factory design pattern.

The idea of ​​class cluster is simple, you often have an abstract class that handles information during initialization, often read as a parameter in a constructor or in the environment, to perform specific logic and instantiate subclasses. This "public facing" class should be aware of its subclasses and return appropriate private subclasses.

This pattern is very useful because it reduces the complexity in the constructor call, only need to know how to communicate with the object interface, not the implementation.

Class clusters are used extensively in Apple's Frameworks: some obvious examples are NSNumber which can return different subclasses to you depending on how the number type is provided (Integer, Float, etc...) or NSArray which returns different subclasses with different optimal storage strategies.

The beauty of this pattern is that the caller can be completely unaware of the subclasses. In fact, this can be used to design a library where you can swap out the actual returned class without worrying about the details because they all follow the methods of the abstract superclass.

Our experience is that using class clusters can help remove many conditional statements.

A classic example of this is if you have the same UIViewController subclass written for iPad and iPhone, but it behaves differently on the different devices.

A more basic implementation would be to use conditional statements to check the device and then perform different logic. Although this might be good at first, as the code grows, the logic will become more complex. A better design would be to create an abstract and broad view controller to contain all the shared logic, and have two special sub-instances for different devices.

The generic view controller will check the current device and return the appropriate subclass.

  1.  @implementation ZOCKintsugiPhotoViewController 
  2.  
  3.  - (id)initWithPhotos:(NSArray *)photos
  4.  {
  5.  if ([self isMemberOfClass:ZOCKintsugiPhotoViewController. class ]) {
  6.  self = nil; 
  7.  
  8.  if ([UIDevice isPad]) {
  9.             self = [[ZOCKintsugiPhotoViewController_iPad alloc] initWithPhotos:photos];
  10.  }
  11.  else {
  12.             self = [[ZOCKintsugiPhotoViewController_iPhone alloc] initWithPhotos:photos];
  13.  }
  14.  return self;
  15.  }
  16.  return [ super initWithNibName:nil bundle:nil];
  17.  } 
  18.  
  19.  @end  

The code example above shows how to create a class cluster. First, [self isMemberOfClass:ZOCKintsugiPhotoViewController.class] is used to avoid overriding the initialization method in the subclass to avoid infinite recursion. When [[ZOCKintsugiPhotoViewController alloc] initWithPhotos:photos] is called, the previous check will become true. Self = nil is used to remove all references to the ZOCKintsugiPhotoViewController instance, which will be released. According to this logic, check which class should be initialized. Let’s assume that this code is run on an iPhone and that ZOCKintsugiPhotoViewController_iPhone does not override initWithPhotos:. In this case, when self = [[ZOCKintsugiPhotoViewController_iPhone alloc] initWithPhotos:photos]; is executed, ZOCKintsugiPhotoViewController will be called and when the first check is done, this will not cause the ZOCKintsugiPhotoViewController check to become false and call return [super initWithNibName:nil bundle:nil];, which will allow the initialization to continue and perform the correct initialization of the previous session.

Singleton

If possible, avoid using singletons and use dependency injection instead. However, if you must use it, use a thread-safe pattern to create a shared instance. For GCD, use the dispatch_once() function.

  1.  + (instancetype)sharedInstance
  2.  {
  3.  static id sharedInstance = nil;
  4.  static dispatch_once_t onceToken = 0 ;
  5.    dispatch_once(&onceToken, ^{
  6.       sharedInstance = [[self alloc] init];
  7.  });
  8.  return sharedInstance;
  9.  }

Use dispatch_once() to control code synchronization, replacing the original conventional usage.

  1.  + (instancetype)sharedInstance
  2.  {
  3.  static id sharedInstance;
  4.  @synchronized (self) {
  5.  if (sharedInstance == nil) {
  6.             sharedInstance = [[MyClass alloc] init];
  7.  }
  8.  }
  9.  return sharedInstance;
  10.  }

The advantage of dispatch_once() is that it is faster and syntactically cleaner, because dispatch_once() means "execute something once", just like we did. This also avoids possible and sometimes prolific crashes.

The classic example of a singleton object is a device's GPS and motion sensors. Even though singleton objects can be subclassed, this can be useful. The interface should justify the intent of a given class to be a singleton. However, a single public sharedInstance class method is usually sufficient, and non-writable properties should be exposed.

Using a singleton as a container of objects to be shared across code or application level is bad and ugly and is a bad design.

property

Attributes should be named as descriptively as possible, avoid abbreviations, and are camel names starting with lowercase letters. Our tools can easily help us automatically complete everything (well.. Almost all, Xcode's Derived Data indexes these names). So there is no reason to type a few characters less, and it is best to express as much as possible in your source code.

example:

  1.  NSString *text;

Don't do this:

  1.  NSString* text;
  2.  NSString * text;

(Note: This habit is different from constants, which is mainly considered from common use and readability. C++ developers prefer to separate types from variable names, as type it should be in the NSString* (for objects allocated from the heap, for C++, it can be allocated from the stack).)

Use automatic synchronization of properties instead of manual @synthesize statements, unless your property is part of the protocol instead of a complete class. If Xcode can synchronize these variables automatically, let it do it. Otherwise, it will only let you put aside the advantages of Xcode and maintain more verbose code.

You should always use the setter and getter methods to access properties, except for the init and dealloc methods. Usually, using properties allows you to increase the possibility of blocks of code outside the current scope so there may be more side effects.

You should always use getter and setter because:

  • Using a setter will comply with the defined memory management semantics (strong, weak, copy etc...) , which was related before ARC. For example, the copy property defines that when you use a setter and transfer data, it will copy the data without additional operations.
  • KVO notifications (willChangeValueForKey, didChangeValueForKey) will be executed automatically.
  • Easier to debug: You can set a breakpoint on the property declaration and the breakpoint will be executed every time the getter/setter method is called, or you can set a breakpoint in your own custom setter/getter.
  • Allows additional logic to set values ​​in a separate place.

You should tend to use getters:

  • It has the ability to expand future changes (for example, attributes are automatically generated).
  • It allows subclassing.
  • Simpler debug (for example, allowing a breakpoint to be taken in the getter method and see who accesses the special getter
  • It makes the intention clearer and clearer: by accessing ivar _anIvar you can explicitly access self->_anIvar. This can cause problems. Access ivar in the block (you capture and retain self, even if you don't explicitly see the self keyword).
  • It automatically generates KVO notifications.
  • The added overhead when the message is sent is insignificant. For more information about the New Year issues, you can see Should I Use a Property or an Instance Variable?.

#p#

Init and Dealloc

There is an exception: you can never use getter and setter methods in init (and other initialization functions), and you directly access the instance variables. In fact, a subclass can overload setter or getter and try to call other methods, access attributes or ivar, they may not be fully initialized. Remember that an object is considered to be initialized to a state only when init returns.

Also in the dealloc method (in the dealloc method, an object can be in an uncertain state) this also needs to be noted.

  • Advanced Memory Management Programming Guide under the self-explanatory section "Don't Use Accessor Methods in Initializer Methods and dealloc";
  • Migrating to Modern Objective-C at WWDC 2012 at slide 27;
  • in a pull request form Dave DeLong's.

Additionally, using setters in init won't execute the UIAppearence proxy well (see UIAppearance for Custom Views for more information).

Point symbol

When using the setter getter method, try to use dot symbols. You should always use dot symbols to access and set properties.

example:

  1.  view.backgroundColor = [UIColor orangeColor];
  2.  [UIApplication sharedApplication].delegate;

Don't do this:

  1.  [view setBackgroundColor:[UIColor orangeColor]];
  2.  UIApplication.sharedApplication.delegate;

Using dot notation will make the expression clearer and help distinguish between property access and method calls

Property Definition

It is recommended to define attributes in the following format

  1.  @property (nonatomic, readwrite, copy) NSString *name;

The parameters of the attributes should be arranged in the following order: atomicity, read-write and memory management. This way, your attributes are easier to modify correctly and are easier to read.

You must use nonatomic unless otherwise required. In iOS, the locks brought by atomic particularly affect performance.

The attribute can store a code block. In order to survive until the end of the defined block, copy must be used (block was first created in the stack, and copy was used to copy the block into the heap)

In order to complete a common getter and a private setter, you should declare the public property as readonly and redefine the common property as readwrite in the class extension.

  1.  @interface MyClass: NSObject
  2.  @property (nonatomic, readonly) NSObject *object
  3.  @end   
  4.  
  5.  @interface MyClass ()
  6.  @property (nonatomic, readwrite, strong) NSObject *object
  7.  @end  

If the name of the BOOL attribute is descriptive, this attribute can be omitted "is" but it is specific to specify the name in the get accessor, such as:

  1.  @property (assign, getter=isEditable) BOOL editable;

Text and examples are quoted from Cocoa Naming Guidelines.

In order to avoid the use of @synthesize, Xcode has automatically added it to you in the implementation file.

Private attributes

Private attributes should be in class extensions (class extensions, categories without names) of the class implementation file. Categories with names (if ZOCPrivate) should not be used unless the other class is expanded.

example:

  1.  @interface ZOCViewController ()
  2.  @property (nonatomic, strong) UIView *bannerView;
  3.  @end  

Variable Objects

Any memory management type that can be used to set (such as NSString, NSArray, NSURLRequest) attributes that can be used to set with a variable object must be copy.

This is used to ensure the wrapping and avoid changing the value without the object knowing it.

You should also avoid exposing mutable objects in exposed interfaces, as this allows consumers of your class to change your own internal representation and break the encapsulation. You can provide properties that can be read-only to return an immutable copy of your object.

  1.  /* .h */  
  2.  @property (nonatomic, readonly) NSArray *elements 
  3.  
  4.  /* .m */  
  5.  - (NSArray *)elements {
  6.  return [self.mutableElements copy];
  7.  }

Lazy Loading

When instantiating an object, it may take a lot of resources, or it needs to be configured only once and there are some configuration methods that need to be called, and you don't want to mess with these methods.

In this case, we can choose to use the getter method of overloading properties to do lazy instantiation. Usually the template for this operation looks like this:

  1.  - (NSDateFormatter *)dateFormatter {
  2.  if (!_dateFormatter) {
  3.     _dateFormatter = [[NSDateFormatter alloc] init];
  4.         NSLocale *enUSPOSIXLocale = [[NSLocale alloc] initWithLocaleIdentifier:@ "en_US_POSIX" ];
  5.         [dateFormatter setLocale:enUSPOSIXLocale];
  6.         [dateFormatter setDateFormat:@ "yyyy-MM-dd'T'HH:mm:ss.SSSSS" ];
  7.  }
  8.  return _dateFormatter;
  9.  }

Even if this is good in some cases, it should be thoughtful before actually doing so. In fact, such practices are avoidable. Here is the controversy about using delayed instantiation.

  • The getter method should not have side effects. When using the getter method, don't think that it may create an object or cause side effects. In fact, if the returned object is not involved when calling the getter method, the compiler will issue a warning: getter should not have side effects.
  • You changed the initialization consumption on the first visit, resulting in side effects, making it difficult to optimize performance (and test)
  • This initialization may be uncertain: for example, you expect the property to be accessed by a method for the first time, but you change the implementation of the class and the accessor is called before you expect it, which can cause problems, especially when the initialization logic may depend on other different states of the class. In general, it is best to explicitly define the dependencies.
  • This behavior is not KVO friendly. If the getter changes the reference, it should notify the change through a KVO notification. It is strange to receive a change notification when accessing the getter.

method

Parameter Assertion

Your method may require some parameters to satisfy a specific condition (such as not nil). In this case, it is best to use NSParameterAssert() to assert whether the condition is true or an exception is thrown.

Private method

Never prefix your private method. This prefix is ​​reserved by Apple. Don't risk overloading Apple's private method.

Equality

Remember this convention when you want to achieve equality: you need to implement both isEqual and hash methods. If two objects are considered equal by isEqual, their hash method needs to return the same value. However, if hash returns the same value, it does not ensure that they are equal.

This convention is because of how to find these objects when stored in a collection (such as NSDictionary and NSSet data structures that use hash table data at the underlying level).

  1.  @implementation ZOCPerson 
  2.  
  3.  - (BOOL)isEqual:(id)object {
  4.  if (self == object) {
  5.  return YES;
  6.  } 
  7.  
  8.  if (![object isKindOfClass:[ZOCPerson class ]]) {
  9.  return NO;
  10.  } 
  11.  
  12.  // check objects properties (name and birthday) for equality  
  13.  ...
  14.  return propertiesMatch;
  15.  } 
  16.  
  17.  - (NSUInteger)hash {
  18.  return [self.name hash] ^ [self.birthday hash];
  19.  } 
  20.  
  21.  @end  

Be sure to note that the hash method cannot return a constant. This is a typical error and can cause serious problems, because using this value as the key of the hash table will cause 100% collisions in the hash table.

You should always implement an equality check method using isEqualTo<#class-name-without-prefix#>: format. If you do this, you will be called first to avoid the above type check.

A complete isEqual method should look like this:

  1.  - (BOOL)isEqual:(id)object {
  2.  if (self == object) {
  3.  return YES;
  4.  } 
  5.  
  6.  if (![object isKindOfClass:[ZOCPerson class ]]) {
  7.  return NO;
  8.  } 
  9.  
  10.  return [self isEqualToPerson:(ZOCPerson *)object];
  11.  } 
  12.  
  13.  - (BOOL)isEqualToPerson:(Person *)person {
  14.  if (!person) {
  15.  return NO;
  16.  } 
  17.  
  18.     BOOL namesMatch = (!self.name && !person.name) ||
  19.                        [self.name isEqualToString:person.name];
  20.     BOOL birthdaysMatch = (!self.birthday && !person.birthday) ||
  21.                            [self.birthday isEqualToDate:person.birthday]; 
  22.  
  23.  return haveEqualNames && haveEqualBirthdays;
  24.  }

The hash calculation result of an object instance should be deterministic. This is important when it is added to a container object (such as NSArray, NSSet, or NSDictionary), otherwise the behavior will not be predicted (all container objects use the object's hash to find or implement special behavior, such as determining uniqueness). This means that the hash value should be calculated using immutable properties, or it is best to ensure that the object is immutable.

#p#

Categories

Although we know that writing this way is ugly, we should add our own lowercase prefix and underscore before our category method, such as - (id)zoc_myCategoryMethod. This practice is also recommended by Apple.

This is very necessary. Because if the same method name is already used in the extended category or other category, it will lead to unpredictable consequences. In fact, the method that is actually called is the last implemented method.

If you want to confirm that your classification method does not overwrite other implementations, you can set the environment variable OBJC_PRINT_REPLACED_METHODS to YES, so that the replaced method names will be printed to the Console. Now LLVM 5.1 will not issue any warnings or errors for this, so be careful not to overload methods in the classification.

A good practice is to use prefixes in category names.

** example**

  1.  @interface NSDate (ZOCTimeExtensions)
  2.  - (NSString *)zoc_timeAgoShort;
  3.  @end  

** Don't do this**

  1.  @interface NSDate (ZOCTimeExtensions)
  2.  - (NSString *)timeAgoShort;
  3.  @end  

Classification can be used to define a set of similar methods in header files. This is also a common practice in Apple's Framework (the following example is taken from the NSDate header file). We also strongly recommend this in our own code.

Our experience is that creating a set of classes is very helpful for future reconstruction. When an interface to a class is added, it may mean that your class does too many things, which violates the single function principle of the class.

The grouping of methods created earlier can be used to better represent different functions and break the classes into more self-contained components.

  1.  @interface NSDate : NSObject <NSCopying, NSSecureCoding> 
  2.  
  3.  @property (readonly) NSTimeInterval timeIntervalSinceReferenceDate; 
  4.  
  5.  @end   
  6.  
  7.  @interface NSDate (NSDateCreation) 
  8.  
  9.  + (instancetype)date;
  10.  + (instancetype)dateWithTimeIntervalSinceNow:(NSTimeInterval)secs;
  11.  + (instancetype)dateWithTimeIntervalSinceReferenceDate:(NSTimeInterval)ti;
  12.  + (instancetype)dateWithTimeIntervalSince1970:(NSTimeInterval)secs;
  13.  + (instancetype)dateWithTimeInterval:(NSTimeInterval)secsToBeAdded sinceDate:(NSDate *)date;
  14.  // ...  
  15.  @end  

Protocols

One thing that is often missed in the world of Objective-C is abstract interface. The word interface usually refers to a class of .h files, but it has another meaning in the eyes of Java programmers: a series of definitions of methods that do not rely on specific implementations.

In Objective-C, abstract interfaces are implemented through protocol. For historical reasons, protocol (used as a Java interface) is not widely used in the Objective-C community. One main reason is that most Apple-developed code does not include it, and almost all developers follow Apple's pattern and guidelines. Apple almost only uses protocol in delegate mode.

But the concept of abstract interface is very powerful, it has originated in the history of computer science, and there is no reason not to be used in Objective-C.

We will explain the power of protocol (used as an abstract interface) and use concrete examples to transform a very bad design architecture into a good reusable code.

This example is to implement an RSS subscription reader (it is often used as a test question in technical interviews).

The requirement is simple and straightforward: display a remote RSS subscription in a tableview.

A naive way is to create a subclass of UITableViewController and put all the search subscription data, parsing and presentation logic together, or a Massive View Controller. This can run, but it is a bad design, but it's enough to pass some low-demand interviews.

The smallest step is to follow the single function principle and create at least two components to accomplish this task:

  • A feed parser to parse the collected results
  • A feed reader to display results

The interfaces of these classes can be like this:

  1.  @interface ZOCFeedParser : NSObject 
  2.  
  3.  @property (nonatomic, weak) id <ZOCFeedParserDelegate> delegate;
  4.  @property (nonatomic, strong) NSURL *url; 
  5.  
  6.  - (id)initWithURL:(NSURL *)url; 
  7.  
  8.  - (BOOL)start;
  9.  - ( void )stop; 
  10.  
  11.  @end  
  1.  @interface ZOCTableViewController : UITableViewController 
  2.  
  3.  - (instancetype)initWithFeedParser:(ZOCFeedParser *)feedParser; 
  4.  
  5.  @end  

ZOCFeedParser is initialized with an NSURL to get an RSS subscription (under which one may use NSXMLParser and NSXMLParserDelegate to create meaningful data), and ZOCTableViewController will use this parser to initialize. We want it to display the value received by parser and we implement the delegate with the following protocol:

  1.  @protocol ZOCFeedParserDelegate <NSObject>
  2.  @optional  
  3.  - ( void )feedParserDidStart:(ZOCFeedParser *)parser;
  4.  - ( void )feedParser:(ZOCFeedParser *)parser didParseFeedInfo:(ZOCFeedInfoDTO *)info;
  5.  - ( void )feedParser:(ZOCFeedParser *)parser didParseFeedItem:(ZOCFeedItemDTO *)item;
  6.  - ( void )feedParserDidFinish:(ZOCFeedParser *)parser;
  7.  - ( void )feedParser:(ZOCFeedParser *)parser didFailWithError:(NSError *)error;
  8.  @end  

It's perfect to handle RSS with the right protocol. The view controller will follow its exposed interface:

  1.  @interface ZOCTableViewController : UITableViewController <ZOCFeedParserDelegate>

The last code created looks like this:

  1.  NSURL *feedURL = [NSURL URLWithString:@ "http://bbc.co.uk/feed.rss" ]; 
  2.  
  3.  ZOCFeedParser *feedParser = [[ZOCFeedParser alloc] initWithURL:feedURL]; 
  4.  
  5.  ZOCTableViewController *tableViewController = [[ZOCTableViewController alloc] initWithFeedParser:feedParser];
  6.  feedParser.delegate = tableViewController;

Until now, you may think your code is pretty good, but how much code can be reused effectively? The view controller can only handle objects of type ZOCFeedParser: From this point of view, we just separate the code into two components, without doing anything other valuable.

The responsibility of the view controller should be to "show what something provides", but this is not the case if we only allow the ZOCFeedParser to be passed. This reflects the need to pass to the view controller a more generic object.

We use ZOCFeedParserProtocol (in the ZOCFeedParserProtocol.h file, and there is also ZOCFeedParserDelegate in the file).

  1.  @protocol ZOCFeedParserProtocol <NSObject> 
  2.  
  3.  @property (nonatomic, weak) id <ZOCFeedParserDelegate> delegate;
  4.  @property (nonatomic, strong) NSURL *url; 
  5.  
  6.  - (BOOL)start;
  7.  - ( void )stop; 
  8.  
  9.  @end   
  10.  
  11.  @protocol ZOCFeedParserDelegate <NSObject>
  12.  @optional  
  13.  - ( void )feedParserDidStart:(id<ZOCFeedParserProtocol>)parser;
  14.  - ( void )feedParser:(id<ZOCFeedParserProtocol>)parser didParseFeedInfo:(ZOCFeedInfoDTO *)info;
  15.  - ( void )feedParser:(id<ZOCFeedParserProtocol>)parser didParseFeedItem:(ZOCFeedItemDTO *)item;
  16.  - ( void )feedParserDidFinish:(id<ZOCFeedParserProtocol>)parser;
  17.  - ( void )feedParser:(id<ZOCFeedParserProtocol>)parser didFailWithError:(NSError *)error;
  18.  @end  

Note that this proxy protocol now processes response to our new protocol, and the interface file of ZOCFeedParser is more refined:

  1.  @interface ZOCFeedParser : NSObject <ZOCFeedParserProtocol> 
  2.  
  3.  - (id)initWithURL:(NSURL *)url; 
  4.  
  5.  @end  

Because ZOCFeedParser implements ZOCFeedParserProtocol, it needs to implement all the required methods. From this point of view, the view controller can accept any object that implements this new protocol, ensuring that all objects will respond from start and stop methods, and it will provide information through the delegate property. All view controllers only need to know the relevant objects and do not need to know the details of the implementation.

  1.  @interface ZOCTableViewController : UITableViewController <ZOCFeedParserDelegate> 
  2.  
  3.  - (instancetype)initWithFeedParser:(id<ZOCFeedParserProtocol>)feedParser; 
  4.  
  5.  @end  

The above code snippet doesn't seem to have many changes, but there is a huge improvement. The view controller is aimed at a protocol rather than a concrete implementation. This brings the following advantages:

  • view controller can any object that can bring information through the delegate property, which can be an RSS remote parser, or a local parser, or a service that reads other remote or local data.
  • ZOCFeedParser and ZOCFeedParserDelegate can be reused by other components
  • ZOCViewController (UI logic part) can be reused
  • Testing is easier because you can use mock objects to achieve the expected effect of protocol

When implementing a protocol, you should always adhere to the Richter replacement principle. This principle is: you should be able to replace any interface (that is, the "protocol" in Objective-C) implementation without changing the client or related implementation.

In addition, this also means that your protocol should not pay attention to the details of the implementation class. When designing the abstract expression of your protocol more carefully, you need to note that it is irrelevant to the underlying implementation, and the protocol is an abstract concept exposed to the user.

Any design that can be reused in the future means that code quality can be improved and it is also the goal of programmers. Whether to design code in this way is the difference between a master and a novices.

The final code can be found here.

#p#

NSNotification

When you define your own NSNotification, you should define the name of your notification as a string constant, just like other string constants you expose to other classes. You should declare it as extern in the exposed interface file and define it in the corresponding implementation file.

Because you exposed symbols in the header file, you should follow the unified namespace prefix rule and use the class name prefix as the prefix for this notification name.

At the same time, it is also a good practice to name this notification with a verb like Did/Will and the suffix of "Notifications".

  1.  // Foo.h  
  2.  extern NSString * const ZOCFooDidBecomeBarNotification 
  3.  
  4.  // Foo.m  
  5.  NSString * const ZOCFooDidBecomeBarNotification = @ "ZOCFooDidBecomeBarNotification" ;

Beautify the code

Space

  • Use 4 spaces to indent. Never use tabs, make sure you set this way in Xcode settings.
  • The braces and other braces of the method (if/else/switch/while, etc.) always start on the same line and end on the new line.

recommend:

  1.  if (user.isHappy) {
  2.  //Do something  
  3.  }
  4.  else {
  5.  //Do something else  
  6.  }

Not recommended:

  1.  if (user.isHappy)
  2.  {
  3.  //Do something  
  4.  } else {
  5.  //Do something else  
  6.  }
  • There should be a blank line between methods to help improve reading clarity and organize the code. Blanks within methods should be used to separate functions, but usually different functions should be defined in new ways. Use auto-synchronization first. But if necessary, @syncthesize and @dynamic
  • A new line should be added to the declaration in the implementation file.
  • The colon should always be aligned. There are some method signatures that may exceed three colons, and aligning with a colon can make the code more readable. Even if there are blocks of code, it should be methoded with a colon.

recommend:

  1.  [UIView animateWithDuration: 1.0  
  2.                  animations:^{
  3.  // something  
  4.  }
  5.                  completion:^(BOOL finished) {
  6.  // something  
  7.  }];

Not recommended:

  1.  [UIView animateWithDuration: 1.0 animations:^{
  2.  // something  
  3.  } completion:^(BOOL finished) {
  4.  // something  
  5.  }];

If automatic alignment makes readability bad, then block should be defined as a variable before, or rethink your code signature design.

Line Break

This guide focuses on the code display and the readability of online browsing, so line breaking is an important topic.

For example:

  1.  self.productsRequest = [[SKProductsRequest alloc] initWithProductIdentifiers:productIdentifiers];

A long line of code like the above continues at one interval (2 spaces) on the second line

  1.  self.productsRequest = [[SKProductsRequest alloc]
  2.   initWithProductIdentifiers:productIdentifiers];

brackets

Use Egyptian style brackets in the following places (Translator's note: also known as K&R style, the beginning of the code segment brackets is at the end of one line, rather than the style that starts with another line. For why it is called Egyptian Brackets, please refer to http://blog.codinghorror.com/new-programming-jargon/ )

  • Control statement (if-else, for, switch)

Non-Egyptian brackets can be used in:

  • Implementation of the class (if it exists)
  • Implementation of the method

Code Organization

From Matttt Thompson

code organization is a matter of hygiene

We agree very much with this statement. It is your respect for yourself and others who read the code clearly and accurately define it.

Using code blocks

A very fuzzy GCC feature, and Clang also has the feature that if the code block is in closed parentheses, it will return the value of the last statement.

  1.  NSURL *url = ({
  2.     NSString *urlString = [NSString stringWithFormat:@ "%@/%@" , baseURLString, endpoint];
  3.     [NSURL URLWithString:urlString];
  4.  });

This feature is very suitable for organizing small pieces of code, usually setting up a class. It gives the reader an important entry and reduces related interference, allowing the reader to focus on key variables and functions. In addition, this method has the advantage that all variables are in the code block, that is, only in the area of ​​the code block, which means that naming pollution to other scopes can be reduced.

Pragma

Pragma Mark

#pragma mark - is a good way to organize code inside a class and help you group methods. We recommend using #pragma mark - to separate:

  • Methods for different functional groups
  • Implementation of protocols
  • Rewrite of parent class method
  1.  - ( void )dealloc { /* ... */ }
  2.  - (instancetype)init { /* ... */ } 
  3.  
  4.  #pragma mark - View Lifecycle (View Lifecycle) 
  5.  
  6.  - ( void )viewDidLoad { /* ... */ }
  7.  - ( void )viewWillAppear:(BOOL)animated { /* ... */ }
  8.  - ( void )didReceiveMemoryWarning { /* ... */ } 
  9.  
  10.  #pragma mark - Custom Accessors 
  11.  
  12.  - ( void )setCustomProperty:(id)value { /* ... */ }
  13.  - (id)customProperty { /* ... */ } 
  14.  
  15.  #pragma mark - IBActions 
  16.  
  17.  - (IBAction)submitData:(id)sender { /* ... */ } 
  18.  
  19.  #pragma mark - Public 
  20.  
  21.  - ( void )publicMethod { /* ... */ } 
  22.  
  23.  #pragma mark - Private 
  24.  
  25.  - ( void )zoc_privateMethod { /* ... */ } 
  26.  
  27.  #pragma mark - UITableViewDataSource 
  28.  
  29.  - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { /* ... */ } 
  30.  
  31.  #pragma mark - ZOCSuperclass 
  32.  
  33.  // ... Overload the method from ZOCSuperclass   
  34.  
  35.  #pragma mark - NSObject 
  36.  
  37.  - (NSString *)description { /* ... */ }

The above marks can clearly separate and organize the code. You can also use cmd+Click to quickly jump to the symbol definition place. But be careful, even if paragma mark is a craft, it is not a reason to increase the number of methods in your class: there are too many methods in the class that indicate that the class does too many things and needs to be considered for reconstruction.

#p#

About pragma

There is a good discussion about pragma at http://raptureinvenice.com/pragmas-arent-just-for-marks, so let's explain it in part here.

Most iOS developers don't usually deal with many compiler options. Some options are strictly checking (or not checking) your code or errors. Sometimes, you want to use pragma to directly generate an exception, temporarily interrupting the compiler's behavior.

When you use ARC, the compiler helps you insert memory management-related calls. But this may cause some annoying things. For example, when you use NSSelectorFromString to dynamically generate a selector call, ARC does not know which method this method is and does not know which memory management method should be used. You will be prompted that performSelector may cause a leak because its selector is unknown (executing the selector may cause a leak because this selector is unknown).

If you know that your code will not cause memory leaks, you can ignore these warnings by adding these codes

  1.  #pragma clang diagnostic push
  2.  #pragma clang diagnostic ignored "-Warc-performSelector-leaks"   
  3.  
  4.  [myObj performSelector:mySelector withObject:name]; 
  5.  
  6.  #pragma clang diagnostic pop

Notice how we disable the -Warc-performSelector-leaks check with pragma in the relevant code context. This ensures that we are not disabled globally. If disabled globally, it may result in an error.

All options can be found and learned in The Clang User's Manual.

Ignore compile warnings that useless variables

This is useful for indicating that you have a variable that you define but not used. Most of the time, you want to remove these references (slightly) to improve performance, but sometimes you want to keep them. Why? Maybe they are useful later, or some features are just temporarily removed. Anyway, a good way to eliminate these warnings is to annotate with relevant statements, using #pragma unused():

  1.  - ( void )giveMeFive
  2.  {
  3.  NSString *foo;
  4.  #pragma unused (foo) 
  5.  
  6.  return   5 ;
  7.  }

Now your code does not require any compilation warnings. Note that your pragma needs to be marked under undefined variables.

Identify compiler warnings and errors

A compiler is a robot that marks the errors in your code by Clang rules. However, you are always smarter than Clang. Usually, you will find that some annoying code can cause this problem, but it cannot be solved for the time being. You can clarify an error like this:

  1.  - (NSInteger)divide:(NSInteger)dividend by:(NSInteger)divisor
  2.  {
  3.     #error Whoa, buddy, you need to check for zero here!
  4.  return (dividend / divisor);
  5.  }

Similarly, you can indicate a warning like this

  1.  - ( float )divide:( float )dividend by:( float )divisor
  2.  {
  3.     #warning Dude, don't compare floating point numbers like this !
  4.  if (divisor != 0.0 ) {
  5.  return (dividend / divisor);
  6.  }
  7.  else {
  8.  return NAN;
  9.  }
  10.  }

String Documents

All important methods, interfaces, classifications, and protocol definitions should have accompanying comments to explain their use and how to use them. For more examples, see File and Declaration Comments in the Google Code Style Guide.

In short: There are two string documents, long and short.

Short documents are suitable for single-line files, including comment slashes. It is suitable for short functions, especially (but not just) non-public APIs:

  1.  // Return a user-readable form of a Frobnozz, html-escaped.  

The text should be described with a verb ("return") instead of "returns".

If the description exceeds one line, you should start the block document with a long string: a line of slashes and two asterisks (/**, followed by a summary sentence. You can end with a period, a question mark or an exclamation mark, then empty the line, write the remaining comments in line with the first sentence, and then end with a (*/).

  1.  /**
  2.  This comment serves to demonstrate the format of a docstring. 
  3.  
  4.  Note that the summary line is always at most one line long, and
  5.  after the opening block comment, and each line of text is preceded
  6.  by a single space.
  7.  */  

A function must have a string document unless it meets all the following conditions:

  • Non-public
  • Very short
  • It's obvious

The string documentation should describe the calling symbol and semantics of a function, not how it is implemented.

Notes

When it is needed, comments should be used to explain what the specific code does. All comments must be maintained continuously or simply deleted.

Block comments should be avoided, and the code itself should represent intent as much as the document can, requiring very few interruptions. Exception: This cannot be applied to comments used to produce documents

Header Document

Documents of a class should only be written in the .h file in the syntax of Doxygen/AppleDoc. Both methods and properties should provide documentation.

*example: *

  1.  /**
  2.  * Designated initializer.
  3.  *
  4.  *  @param  store  The store for CRUD operations.
  5.  *  @param  searchService The search service used to query the store.
  6.  *
  7.  *  @return A ZOCCRUDOperationsStore object.
  8.  */  
  9.  - (instancetype)initWithOperationsStore:(id<ZOCGenericStoreProtocol>)store
  10.                           searchService:(id<ZOCGenericSearchServiceProtocol>)searchService;

Communication between objects

Communication between objects is required, which is the basis of all software. No matter how extraordinary software is, it needs to achieve complex goals through object communication. This chapter will discuss in-depth some design concepts and how to design a good architecture based on these concepts.

Blocks

Blocks are Objective-C versions of lambda or closure (closure).

Use block to define an asynchronous interface:

  1.  - ( void )downloadObjectsAtPath:(NSString *)path
  2.                    completion:( void (^)(NSArray *objects, NSError *error))completion;

When you define an interface similar to the above, try to use a separate block as the last parameter of the interface. It is better to integrate the data and error information needed to be provided into a separate block than to provide successful and failed blocks respectively.

Here are the reasons you should do this:

  • Usually this successful processing and failure processing will share some code (such as making a progress bar or prompt disappear);
  • Apple does the same, and being consistent with the platform can bring some potential benefits;
  • Block usually has multiple lines of code, which will break the call point if it is not in the last parameter;
  • Using multiple blocks as arguments can make the call appear clumsy and add complexity.

Looking at the above method, the parameters of blocks that are processed are very common: the first parameter is the data the caller wants to obtain, and the second is the information related to errors. The following two points need to be followed here:

  • If objects are not nil, then error must be nil
  • If objects are nil, error must not be nil

Because the caller cares more about the actual data, like this:

  1.  - ( void )downloadObjectsAtPath:(NSString *)path
  2.                    completion:( void (^)(NSArray *objects, NSError *error))completion {
  3.  if (objects) {
  4.  // do something with the data  
  5.  }
  6.  else {
  7.  // some error occurred, 'error' variable should not be nil by contract  
  8.  }
  9.  }

In addition, some synchronization interfaces provided by Apple write garbage values ​​to the error parameter (if non-NULL) in a successful state, so checking the error value may be problematic.

#p#

In-depth Blocks

Some key points:

  • block is created on the stack
  • block can be copied to the heap
  • block has its own private stack variables (and pointers) constant copying
  • Variables and pointers on a variable stack must be declared with the __block keyword

If the block is not held elsewhere, it will survive with the stack and disappear when the stack frame returns. When on the stack, a block has no effect on anything accessed. If the block needs to exist when the stack frame returns, they need to be explicitly copied to the heap, so the block will increase the reference count like other Cocoa objects. When they are copied, it will take their capture scope together and retain all the objects they refer to. If a block points to a stack variable or pointer, then when the block is initialized, it will have a copy declared as const, so it is useless to assign values ​​to them. When a block is copied, the reference to the stack variable declared by __block is copied to the heap, and after copying, the block on the stack and the generated heap will refer to the variable on the heap.

Use LLDB to show blocks like this:

The most important thing is that the variables and pointers declared by __block are treated in the block as structures that display the operation's real value/object.

block is treated as first-class citizens in Objective-C: they have an isa pointer, and a class also uses an isa pointer to access the Objective-C runtime to access methods and store data. It will definitely make it bad in non-ARC environments, and hanging pointers will cause Crash. __block only works on variables inside the block, it simply tells the block:

Hi, this pointer or primitive type depends on the stack they are on. Please refer to it with a new variable on the stack. I mean, please double dereference it and don't retain it. Thanks, buddy.

If the object is released after definition but before the block is called, the execution of the block will cause Crash. The __block variable is not held in the block, and finally... pointers, references, dereferences, and reference counts become a mess.

The circular reference of self

When using code blocks and asynchronous distribution, be careful to avoid reference loops. Always using weak references will lead to reference loops. In addition, setting the property holding blocks to nil (such as self.completionBlock = nil) is a good practice. It will break the reference loops brought by the scope captured by blocks.

example:

  1.  __weak __typeof(self) weakSelf = self;
  2.  [self executeBlock:^(NSData *data, NSError *error) {
  3.     [weakSelf doSomethingWithData:data];
  4.  }];

Don't do this:

  1.  [self executeBlock:^(NSData *data, NSError *error) {
  2.     [self doSomethingWithData:data];
  3.  }];

Examples of multiple statements:

  1.  __weak __typeof(self)weakSelf = self;
  2.  [self executeBlock:^(NSData *data, NSError *error) {
  3.     __strong __typeof(weakSelf) strongSelf = weakSelf;
  4.  if (strongSelf) {
  5.         [strongSelf doSomethingWithData:data];
  6.         [strongSelf doSomethingWithData:data];
  7.  }
  8.  }];

Don't do this:

  1.  __weak __typeof(self)weakSelf = self;
  2.  [self executeBlock:^(NSData *data, NSError *error) {
  3.     [weakSelf doSomethingWithData:data];
  4.     [weakSelf doSomethingWithData:data];
  5.  }];

You should add these two lines of code to Xcode as snippet and always use them like this.

  1.  __weak __typeof(self)weakSelf = self;
  2.  __strong __typeof(weakSelf)strongSelf = weakSelf;

Here we will discuss some subtleties of self's __weak and __strong qualifiers in block. In short, we can refer to the three different situations in self in block.

  • Use the keyword self directly in the block
  • Define a reference of __weak to self outside the block, and use this weak reference in the block
  • Define a reference of __weak to self outside the block, and define a reference of __strong within the block through this weak reference.

1. Use the keyword self directly in the block

If we use the self keyword directly in the block, the object will be retained when the block is defined (in fact, block is copied, but for simplicity we can ignore this). A const reference to self has its own position in the block and it will affect the object's reference count. If the block is transmitted by other classes or/and it may want to retain self like other objects used by block, from which they need to be executed by block.

  1.  dispatch_block_t completionBlock = ^{
  2.  NSLog(@ "%@" , self);
  3.  } 
  4.  
  5.  MyViewController *myController = [[MyViewController alloc] init...];
  6.  [self presentViewController:myController
  7.                    animated:YES
  8.                  completion:completionHandler];

Not a very troublesome thing. But when the block is self in a property retain (like the following example)

  1.  self.completionHandler = ^{
  2.  NSLog(@ "%@" , self);
  3.  } 
  4.  
  5.  MyViewController *myController = [[MyViewController alloc] init...];
  6.  [self presentViewController:myController
  7.                    animated:YES
  8.                  completion:self.completionHandler];

This is the famous retain cycle, and we should usually avoid it. In this case we receive a warning from CLANG:

  1.  Capturing 'self' strongly in this block is likely to lead to a retain cycle (I found a strong reference of `self` in the block, which may lead to a circular reference)

So it can be modified with weak

2. Define a reference of __weak to self outside the block, and use this weak reference in the block

This will avoid circular references, which is what we usually do when the block has been retained in the property property of self.

  1.  __weak typeof(self) weakSelf = self;
  2.  self.completionHandler = ^{
  3.  NSLog(@ "%@" , weakSelf);
  4.  }; 
  5.  
  6.  MyViewController *myController = [[MyViewController alloc] init...];
  7.  [self presentViewController:myController
  8.                    animated:YES
  9.                  completion:self.completionHandler];

In this case, the block does not have a retain object and the object retains the block in the property. So we can ensure safe access to self. But badly, it may be set to nil. The problem is: if and let self be safely destroyed in the block.

For example, block is copied by one object to another (such as myControler) as the result of attribute assignment. The previous object has the opportunity to execute in the copied block.

The following is more interesting.

3. Define a reference of __weak to self outside the block, and define a reference of __strong within the block through this weak reference.

You might think, first of all, this is a trick to avoid retain cycle warnings. However, this strong reference to self is created at the execution time of the block. When block is defined, block will retain the self object if it uses self.

The Apple documentation says "For non-trivial cycles, you should do this":

  1.  MyViewController *myController = [[MyViewController alloc] init...];
  2.  // ...  
  3.  MyViewController * __weak weakMyController = myController;
  4.  myController.completionHandler =  ^(NSInteger result) {
  5.     MyViewController *strongMyController = weakMyController;
  6.  if (strongMyController) {
  7.  // ...  
  8.         [strongMyController dismissViewControllerAnimated:YES completion:nil];
  9.  // ...  
  10.  }
  11.  else {
  12.  // Probably nothing...  
  13.  }
  14.  };

First of all, I think this example looks wrong. If the block itself is retained in the completionHandler property, how can self be assigned to nil by delloc and outside the block? The completionHandler property can be declared assign or unsafe_unretained to allow the object to be destroyed after the block is passed.

I can't understand the reason for doing this. If other objects need this object (self), the block should retain the object when it is passed, so the block should not be stored as a property. In this case, __weak/__strong should not be used

In short, in other cases, if you want weakSelf to become nil, it is written like the second case explanation (define a weak application outside the block and use it in the block).

Also, what is Apple's "trivial block". Our understanding is that trivial block is a block that is not transmitted. It is in a well-defined and controlled scope. The weak modification is just to avoid circular references.

While there are some online references discussed by Kazuki Sakamoto and Tomohiko Furumoto, Matt Galloway's (Effective Objective-C 2.0 and Pro Multithreading and Memory Management for iOS and OS X, most developers never figured out the concept.

The advantage of using strong references within a block is that it preempts the robustness during execution. Look at the above three examples, when block is executed

1. Use the keyword self directly in the block

If the block is retained by the property, there will be a circular reference between self and block and they will not be released again. If the block is transmitted and copied by other objects, self is retained in each copy

2. Define a reference of __weak to self outside the block, and use this weak reference in the block

When there is no loop reference, it doesn't matter whether the block is retained or a property. If the block is passed or copied, weakSelf may become nil during execution.

The execution of block can be preempted, and different calls to weakSelf can result in different values ​​(for example, weakSelf may be assigned to nil in a specific execution)

  1.  __weak typeof(self) weakSelf = self;
  2.  dispatch_block_t block = ^{
  3.     [weakSelf doSomething]; // weakSelf != nil  
  4.  // preemption, weakSelf turned nil  
  5.     [weakSelf doSomethingElse]; // weakSelf == nil  
  6.  };

** 3. Define a reference of __weak to self outside the block, and define a reference of __strong through this weak reference inside the block. **

不论管block 是否被retain 或者是一个属性，这样也不会有循环引用。如果block 被传递到其他对象并且被复制了，执行的时候，weakSelf 可能被nil，因为强引用被复制并且不会变成nil的时候，我们确保对象在block 调用的完整周期里面被retain了，如果抢占发生了，随后的对strongSelf 的执行会继续并且会产生一样的值。如果strongSelf 的执行到nil，那么在block 不能正确执行前已经返回了。

  1.  __weak typeof(self) weakSelf = self;
  2.  myObj.myBlock =  ^{
  3.     __strong typeof(self) strongSelf = weakSelf;
  4.  if (strongSelf) {
  5.       [strongSelf doSomething]; // strongSelf != nil  
  6.  // preemption, strongSelf still not nil（抢占的时候，strongSelf 还是非 nil 的)  
  7.       [strongSelf doSomethingElse]; // strongSelf != nil  
  8.  }
  9.  else {
  10.  // Probably nothing...  
  11.  return ;
  12.  }
  13.  };

在一个ARC 的环境中，如果尝试用 ->符号来表示，编译器会警告一个错误：

  1.  Dereferencing a __weak pointer is not allowed due to possible null value caused by race condition,
  2.  assign it to a strong variable first.
  3.  (对一个 __weak 指针的解引用不允许的，因为可能在竞态条件里面变成null , 所以先把他定义成 strong 的属性)

可以用下面的代码展示

  1. __weak typeof(self) weakSelf = self;
  2.  myObj.myBlock =  ^{
  3.     id localVal = weakSelf->someIVar;
  4.  };

at the end

  • 1: 只能在block 不是作为一个property 的时候使用，否则会导致retain cycle。
  • 2: 当block 被声明为一个property 的时候使用。
  • 3: 和并发执行有关。当涉及异步的服务的时候，block 可以在之后被执行，并且不会发生关于self 是否存在的问题。

#p#

委托和数据源

委托是Apple 的框架里面使用广泛的模式，同时它是一个重要的四人帮的书“设计模式”中的模式。委托模式是单向的，消息的发送方（委托方）需要知道接收方（委托），反过来就不是了。对象之间没有多少耦合，因为发送方只要知道它的委托实现了对应的protocol。

本质上，委托模式只需要委托提供一些回调方法，就是说委托实现了一系列空返回值的方法。

不幸的是Apple 的API 并没有尊重这个原则，开发者也效仿Apple 进入了歧途。一个典型的例子是UITableViewDelegate 协议。

一些有void 返回类型的方法就像回调

  1. - ( void )tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath;
  2.  - ( void )tableView:(UITableView *)tableView didHighlightRowAtIndexPath:(NSIndexPath *)indexPath;

但是其他的不是

  1. - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath;
  2.  - (BOOL)tableView:(UITableView *)tableView canPerformAction:(SEL)action forRowAtIndexPath:(NSIndexPath *)indexPath withSender:(id)sender;

当委托者询问委托对象一些信息的时候，这就暗示着信息是从委托对象流向委托者，而不会反过来。 这个概念就和委托模式有些不同，它是一个另外的模式：数据源。

可能有人会说Apple 有一个 UITableViewDataSouce protocol 来做这个（虽然使用委托模式的名字），但是实际上它的方法是用来提供真实的数据应该如何被展示的信息的。

  1.  - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
  2.  - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView;

此外，以上两个方法Apple 混合了展示层和数据层，这显的非常糟糕，但是很少的开发者感到糟糕。而且我们在这里把空返回值和非空返回值的方法都天真地叫做委托方法。

为了分离概念，我们应该这样做：

  • 委托模式：事件发生的时候，委托者需要通知委托
  • 数据源模式: 委托方需要从数据源对象拉取数据

这个是实际的例子：

  1.  @class ZOCSignUpViewController; 
  2.  
  3.  @protocol ZOCSignUpViewControllerDelegate <NSObject>
  4.  - ( void )signUpViewControllerDidPressSignUpButton:(ZOCSignUpViewController *)controller;
  5.  @end   
  6.  
  7.  @protocol ZOCSignUpViewControllerDataSource <NSObject>
  8.  - (ZOCUserCredentials *)credentialsForSignUpViewController:(ZOCSignUpViewController *)controller;
  9.  @end   
  10.  
  11.  @protocol ZOCSignUpViewControllerDataSource <NSObject> 
  12.  
  13.  @interface ZOCSignUpViewController : UIViewController 
  14.  
  15.  @property (nonatomic, weak) id<ZOCSignUpViewControllerDelegate> delegate;
  16.  @property (nonatomic, weak) id<ZOCSignUpViewControllerDataSource> dataSource; 
  17.  
  18.  @end  

在上面的例子里面，委托方法需要总是有一个调用方作为第一个参数，否则委托对象可能被不能区别不同的委托者的实例。此外，如果调用者没有被传递到委托对象，那么就没有办法让一个委托对象处理两个不同的委托者了。所以，下面这样的方法就是人神共愤的：

  1.  - ( void )calculatorDidCalculateValue:(CGFloat)value;

默认情况下，委托对象需要实现protocol 的方法。可以用@required 和 @optional 关键字来标记方法是否是必要的还是可选的。

  1.  @protocol ZOCSignUpViewControllerDelegate <NSObject>
  2.  @required  
  3.  - ( void )signUpViewController:(ZOCSignUpViewController *)controller didProvideSignUpInfo:(NSDictionary *);
  4.  @optional  
  5.  - ( void )signUpViewControllerDidPressSignUpButton:(ZOCSignUpViewController *)controller;
  6.  @end  

对于可选的方法，委托者必须在发送消息前检查委托是否确实实现了特定的方法（否则会Crash）：

  1.  if ([self.delegate respondsToSelector: @selector (signUpViewControllerDidPressSignUpButton:)]) {
  2.     [self.delegate signUpViewControllerDidPressSignUpButton:self];
  3.  }

inherit

有时候你可能需要重载委托方法。考虑有两个UIViewController 子类的情况：UIViewControllerA 和UIViewControllerB，有下面的类继承关系。

UIViewControllerB < UIViewControllerA < UIViewController

UIViewControllerA conforms to UITableViewDelegate and implements - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath.

UIViewControllerA 遵从 UITableViewDelegate 并且实现了 - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath.

你可能会想要提供一个和 UIViewControllerB 不同的实现。一个实现可能是这样子的：

  1.  - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
  2.     CGFloat retVal = 0 ;
  3.  if ([ super respondsToSelector: @selector (tableView:heightForRowAtIndexPath:)]) {
  4.         retVal = [ super tableView:self.tableView heightForRowAtIndexPath:indexPath];
  5.  }
  6.  return retVal + 10 .0f;
  7.  }

但是如果超类(UIViewControllerA)没有实现这个方法呢？

Calling process

  1.  [ super respondsToSelector: @selector (tableView:heightForRowAtIndexPath:)]

会用NSObject 的实现，寻找，在 self 的上下文中无疑有它的实现，但是app 会在下一行Crash 并且报下面的错：

  1.  *** Terminating app due to uncaught exception 'NSInvalidArgumentException' ,
  2.  reason: '-[UIViewControllerB tableView:heightForRowAtIndexPath:]: unrecognized selector sent to instance 0x8d82820'  

这种情况下我们需要来询问特定的类实例是否可以响应对应的selector。下面的代码提供了一个小技巧：

  1.  - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
  2.     CGFloat retVal = 0 ;
  3.  if ([[UIViewControllerA class ] instancesRespondToSelector: @selector (tableView:heightForRowAtIndexPath:)]) {
  4.         retVal = [ super tableView:self.tableView heightForRowAtIndexPath:indexPath];
  5.  }
  6.  return retVal + 10 .0f;
  7.  }

就像上面的丑陋的代码，一个委托方法也比重载方法好。

多重委托

多重委托是一个非常基础的概念，但是，大多数开发者对此非常不熟悉而使用NSNotifications。就像你可能注意到的，委托和数据源是对象之间的通讯模式，但是只涉及两个对象：委托者和委托。

数据源模式强制一对一的关系，发送者来像一个并且只是一个对象来请求信息。但是委托模式不一样，它可以完美得有多个委托来等待回调操作。

至少两个对象需要接收来自特定委托者的回调，并且后一个需要知道所有的委托，这个方法更好的适用于分布式系统并且更加广泛用于大多数软件的复杂信息流传递。

多重委托可以用很多方式实现，读者当然喜欢找到一个好的个人实现，一个非常灵巧的多重委托实现可以参考Luca Bernardi 在他的 LBDelegateMatrioska 的原理。

一个基本的实现在下面给出。Cocoa 在数据结构中使用弱引用来避免引用循环，我们使用一个类来作为委托者持有委托对象的弱引用。

  1.  @interface ZOCWeakObject : NSObject 
  2.  
  3.  @property (nonatomic, weak, readonly) id object; 
  4.  
  5.  + (instancetype)weakObjectWithObject:(id)object;
  6.  - (instancetype)initWithObject:(id)object; 
  7.  
  8.  @end  
  1.  @interface ZOCWeakObject ()
  2.  @property (nonatomic, weak) id object;
  3.  @end   
  4.  
  5.  @implementation ZOCWeakObject 
  6.  
  7.  + (instancetype)weakObjectWithObject:(id)object {
  8.  return [[[self class ] alloc] initWithObject:object];
  9.  } 
  10.  
  11.  - (instancetype)initWithObject:(id)object {
  12.  if ((self = [ super init])) {
  13.         _object = object;
  14.  }
  15.  return self;
  16.  } 
  17.  
  18.  - (BOOL)isEqual:(id)object {
  19.  if (self == object) {
  20.  return YES;
  21.  } 
  22.  
  23.  if (![object isKindOfClass:[object class ]]) {
  24.  return NO;
  25.  } 
  26.  
  27.  return [self isEqualToWeakObject:(ZOCWeakObject *)object];
  28.  } 
  29.  
  30.  - (BOOL)isEqualToWeakObject:(ZOCWeakObject *)object {
  31.  if (!object) {
  32.  return NO;
  33.  } 
  34.  
  35.     BOOL objectsMatch = [self.object isEqual:object.object];
  36.  return objectsMatch;
  37.  } 
  38.  
  39.  - (NSUInteger)hash {
  40.  return [self.object hash];
  41.  } 
  42.  
  43.  @end  

一个简单的使用weak 对象来完成多重引用的组成部分：

  1.  @protocol ZOCServiceDelegate <NSObject>
  2.  @optional  
  3.  - ( void )generalService:(ZOCGeneralService *)service didRetrieveEntries:(NSArray *)entries;
  4.  @end   
  5.  
  6.  @interface ZOCGeneralService : NSObject
  7.  - ( void )registerDelegate:(id<ZOCServiceDelegate>)delegate;
  8.  - ( void )deregisterDelegate:(id<ZOCServiceDelegate>)delegate;
  9.  @end   
  10.  
  11.  @interface ZOCGeneralService ()
  12.  @property (nonatomic, strong) NSMutableSet *delegates;
  13.  @end  
  1.  @implementation ZOCGeneralService
  2.  - ( void )registerDelegate:(id<ZOCServiceDelegate>)delegate {
  3.  if ([delegate conformsToProtocol: @protocol (ZOCServiceDelegate)]) {
  4.         [self.delegates addObject:[[ZOCWeakObject alloc] initWithObject:delegate]];
  5.  }
  6.  } 
  7.  
  8.  - ( void )deregisterDelegate:(id<ZOCServiceDelegate>)delegate {
  9.  if ([delegate conformsToProtocol: @protocol (ZOCServiceDelegate)]) {
  10.         [self.delegates removeObject:[[ZOCWeakObject alloc] initWithObject:delegate]];
  11.  }
  12.  } 
  13.  
  14.  - ( void )_notifyDelegates {
  15.  ...
  16.  for (ZOCWeakObject *object in self.delegates) {
  17.  if (object.object) {
  18.  if ([object.object respondsToSelector: @selector (generalService:didRetrieveEntries:)]) {
  19.                 [object.object generalService:self didRetrieveEntries:entries];
  20.  }
  21.  }
  22.  }
  23.  } 
  24.  
  25.  @end  

在 registerDelegate: 和 deregisterDelegate: 方法的帮助下，连接/解除组成部分很简单：如果委托对象不需要接收委托者的回调，仅仅需要'unsubscribe'.

这在一些不同的view 等待同一个回调来更新界面展示的时候很有用：如果view 只是暂时隐藏（但是仍然存在），它可以仅仅需要取消对回调的订阅。

#p#

面向切面编程

Aspect Oriented Programming (AOP，面向切面编程) 在Objective-C 社区内没有那么有名，但是AOP 在运行时可以有巨大威力。 但是因为没有事实上的标准，Apple 也没有开箱即用的提供，也显得不重要，开发者都不怎么考虑它。

引用 Aspect Oriented Programming 维基页面:

An aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches). (一个切面可以通过在多个join points 中实行advice 改变基础代码的行为(程序的非切面的部分) )

在Objective-C 的世界里，这意味着使用运行时的特性来为 切面 增加适合的代码。通过切面增加的行为可以是：

  • 在类的特定方法调用前运行特定的代码
  • 在类的特定方法调用后运行特定的代码
  • 增加代码来替代原来的类的方法的实现

有很多方法可以达成这些目的，但是我们没有深入挖掘，不过它们主要都是利用了运行时。 Peter Steinberger 写了一个库，Aspects 完美地适配了AOP 的思路。我们发现它值得信赖以及设计得非常优秀，所以我们就在这边作为一个简单的例子。

对于所有的AOP库，这个库用运行时做了一些非常酷的魔法，可以替换或者增加一些方法（比method swizzling 技术更有技巧性）

Aspect 的API 有趣并且非常强大：

  1.  + (id<AspectToken>)aspect_hookSelector:(SEL)selector
  2.                       withOptions:(AspectOptions)options
  3.                        usingBlock:(id)block
  4.                             error:(NSError **)error;
  5.  - (id<AspectToken>)aspect_hookSelector:(SEL)selector
  6.                       withOptions:(AspectOptions)options
  7.                        usingBlock:(id)block
  8.                             error:(NSError **)error;

比如，下面的代码会对于执行 MyClass 类的 myMethod: (实例或者类的方法) 执行块参数。

  1.  [MyClass aspect_hookSelector: @selector (myMethod:)
  2.                  withOptions:AspectPositionAfter
  3.                   usingBlock:^(id<AspectInfo> aspectInfo) {
  4.  ...
  5.  }
  6.                        error:nil];

换一句话说：这个代码可以让在 @selector 参数对应的方法调用之后，在一个 MyClass 的对象上（或者在一个类本身，如果方法是一个类方法的话）执行block 参数。

我们为 MyClass 类的 myMethod: 方法增加了切面。

通常AOP 用来实现横向切面的完美的适用的地方是统计和日志。

下面的例子里面，我们会用AOP用来进行统计。统计是iOS项目里面一个热门的特性，有很多选择比如Google Analytics, Flurry, MixPanel, 等等.

大部分统计框架都有教程来指导如何追踪特定的界面和事件，包括在每一个类里写几行代码。

在Ray Wenderlich 的博客里有 文章 和一些示例代码，通过在你的view controller 里面加入 Google Analytics 进行统计。

  1.  - ( void )logButtonPress:(UIButton *)button {
  2.     id<GAITracker> tracker = [[GAI sharedInstance] defaultTracker];
  3.     [tracker send:[[GAIDictionaryBuilder createEventWithCategory:@ "UX"  
  4.                                                           action:@ "touch"  
  5.                                                            label:[button.titleLabel text]
  6.                                                            value:nil] build]];
  7.  }

上面的代码在按钮点击的时候发送了特定的上下文事件。但是当你想追踪屏幕的时候会更糟糕。

  1.  - ( void )viewDidAppear:(BOOL)animated {
  2.     [ super viewDidAppear:animated]; 
  3.  
  4.     id<GAITracker> tracker = [[GAI sharedInstance] defaultTracker];
  5.     [tracker set:kGAIScreenName value:@ "Stopwatch" ];
  6.     [tracker send:[[GAIDictionaryBuilder createAppView] build]];
  7.  }

对于大部分有经验的iOS工程师，这看起来不是很好的代码。我们让view controller 变得更糟糕了。因为我们加入了统计事件的代码，但是它不是view controller 的职能。你可以反驳，因为你通常有特定的对象来负责统计追踪，并且你将代码注入了view controller ，但是无论你隐藏逻辑，问题仍然存在：你最后还是在viewDidAppear: 后插入了代码。

你可以用AOP 来追踪屏幕视图来修改 viewDidAppear: 方法。同时，我们可以用同样的方法，来在其他感兴趣的方法里面加入事件追踪，比如任何用户点击按钮的时候（比如频繁地调用IBAction）

这个方法是干净并且非侵入性的：

  • 这个view controller 不会被不属于它的代码污染
  • 为所有加入到我们代码的切面定义一个SPOC 文件(single point of customization)提供了可能
  • SPOC 应该在App 刚开始启动的时候就加入切面
  • 公司负责统计的团队通常会提供统计文档，罗列出需要追踪的事件。这个文档可以很容易映射到一个SPOC 文件。
  • 追踪逻辑抽象化之后，扩展到很多其他统计框架会很方便
  • 对于屏幕视图，对于需要定义selector 的方法，只需要在SPOC 文件修改相关的类（相关的切面会加入到 viewDidAppear: 方法）。如果要同时发送屏幕视图和时间，一个追踪的label 和其他元信息来提供额外数据（取决于统计提供方）

我们可能希望一个SPOC 文件类似下面的（同样的一个.plist 文件会适配）

  1.  NSDictionary *analyticsConfiguration()
  2.  {
  3.  return @{
  4.         @ "trackedScreens" : @[
  5.             @{
  6.                 @ "class" : @ "ZOCMainViewController" ,
  7.                 @ "label" : @ "Main screen"  
  8.  }
  9.              ],
  10.         @ "trackedEvents" : @[
  11.             @{
  12.                 @ "class" : @ "ZOCMainViewController" ,
  13.                 @ "selector" : @ "loginViewFetchedUserInfo:user:" ,
  14.                 @ "label" : @ "Login with Facebook"  
  15.  },
  16.             @{
  17.                 @ "class" : @ "ZOCMainViewController" ,
  18.                 @ "selector" : @ "loginViewShowingLoggedOutUser:" ,
  19.                 @ "label" : @ "Logout with Facebook"  
  20.  },
  21.             @{
  22.                 @ "class" : @ "ZOCMainViewController" ,
  23.                 @ "selector" : @ "loginView:handleError:" ,
  24.                 @ "label" : @ "Login error with Facebook"  
  25.  },
  26.             @{
  27.                 @ "class" : @ "ZOCMainViewController" ,
  28.                 @ "selector" : @ "shareButtonPressed:" ,
  29.                 @ "label" : @ "Share button"  
  30.  }
  31.              ]
  32.  };
  33.  }

这个提及的架构在Github 的EF Education First 中托管

  1. - ( void )setupWithConfiguration:(NSDictionary *)configuration
  2.  {
  3.  // screen views tracking  
  4.  for (NSDictionary *trackedScreen in configuration[@ "trackedScreens" ]) {
  5.         Class clazz = NSClassFromString(trackedScreen[@ "class" ]); 
  6.  
  7.         [clazz aspect_hookSelector: @selector (viewDidAppear:)
  8.                        withOptions:AspectPositionAfter
  9.                         usingBlock:^(id<AspectInfo> aspectInfo) {
  10.             dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0 ), ^{
  11.                 NSString *viewName = trackedScreen[@ "label" ];
  12.                 [tracker trackScreenHitWithName:viewName];
  13.  });
  14.  }]; 
  15.  
  16.  } 
  17.  
  18.  // events tracking  
  19.  for (NSDictionary *trackedEvents in configuration[@ "trackedEvents" ]) {
  20.         Class clazz = NSClassFromString(trackedEvents[@ "class" ]);
  21.         SEL selektor = NSSelectorFromString(trackedEvents[@ "selector" ]); 
  22.  
  23.         [clazz aspect_hookSelector:selektor
  24.                        withOptions:AspectPositionAfter
  25.                         usingBlock:^(id<AspectInfo> aspectInfo) {
  26.             dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0 ), ^{
  27.                 UserActivityButtonPressedEvent *buttonPressEvent = [UserActivityButtonPressedEvent eventWithLabel:trackedEvents[@ "label" ]];
  28.                 [tracker trackEvent:buttonPressEvent];
  29.  });
  30.  }]; 
  31.  
  32.  }
  33.  }

References

这里有一些和风格指南有关的苹果的文档：

  • The Objective-C Programming Language
  • Cocoa Fundamentals Guide
  • Coding Guidelines for Cocoa
  • iOS App Programming Guide
  • Apple Objective-C conventions: 来自苹果的代码约定

other:

  • Objective-Clean: an attempt to write a standard for writing Objective-C code with Xcode integration;
  • Uncrustify: source code beautifier.

其他的Objective-C 风格指南

这里有一些和风格指南有关的苹果的文档。如果有一些本书没有涉猎的地方，你或许能在这些之中找到详细说明。

来自Apple 的：

  • The Objective-C Programming Language
  • Cocoa Fundamentals Guide
  • Coding Guidelines for Cocoa
  • iOS App Programming Guide

来自社区的：

  • NYTimes Objective-C Style Guide
  • Google
  • GitHub
  • Adium
  • Sam Soffes
  • CocoaDevCentral
  • Luke Redpath
  • Marcus Zarra
  • Ray Wenderlich

<<:  [Recommended by Zhihu] Those Android development tools that you can’t stop using

>>:  APP UI design trends: moving for good design

Recommend

Six major questions facing Apple's core products

As is Cook's usual style, he will certainly c...

How to create a hit product through seed user operations?

Seed users generally have an open and adventurous...

Why are used car e-commerce companies so keen on "advertising"?

Starting from a few days ago, you can already see...

Java vs. Node.js: An Epic Battle

[[160272]] Image source: Photo by Flickr user Tsu...

WeChat bank card payment prompt error: three steps to find out the reason

What should I do if an error message appears when...

Case Study: Review of Tmall’s 21-Day Vitality Plan

From the news on April 10th that Yi Yang Qianxi w...

A guide to game industry splash screen design based on 1000+ case studies

Based on the analysis of 1000+ splash screen mate...

Analysis of Pinduoduo’s “Shake for Cash” campaign operations!

Have you participated in Pinduoduo’s “Shake for C...

Google advertising promotion, how to position Google display ads?

Everyone knows that Google search ads are directl...

Marketing promotion method: the winning secret of gamification marketing!

Introduction: The success of gamification marketi...

How to make Tik Tok? 6 operation and promotion techniques of Tik Tok!

There are two main points to focus on when doing ...

Night Grass and the Thousand-Li Horse Edmund "Short Video Copywriting Course that Can Be Popular Just by Talking" Episode 19

Training course video lecture content introductio...

SaaS product solutions for the fresh fruit industry

The 2020 epidemic accelerated the digitalization ...

2020 Hubei Provincial College Entrance Examination Xiangyang Liberal Arts and Science Champions: Zhu Caiye, Yue Kun

In the early morning of July 23, the channel for ...

Methodology: 99% of brands have poor product selling points

Through this article, you will have a very system...