About Dealloc Precautions

The following discussion is under MRC.

1, do not use accessor in the init and Dealloc functions

 in Set in Object object as follows:

Refs:https://developer.apple.com/library/mac/documentation/cocoa/conceptual/memorymgmt/articles/mmpractical.html

Dealloc implementation:

Not recommended:

-(void) dealloc {     = nil;     [Super Dealloc]}

Recommended:

-(void) dealloc {
     [_name release];      = Nil;     [Super Dealloc]}

Init implementation:

Not recommended:

- init {    = [Super init];     if (self) {        = [[NSNumber alloc] Initwithinteger:0];    }     return Self ;}

Recommended:

- init {    = [Super init];     if (self) {        = [[NSNumber alloc] Initwithinteger:0];    }     return Self ;}

Why: For the use of the self.name accessor in Init, there are other side effects that may be notified of key-value observations (KVO), or if your subclass overloads the property accessor for name (the subclass overrides the implementation of the parent class. ）

If custom implements the following, there is an attribute of count.

- init {    = [Super init];     if (self) {        = [[NSNumber alloc] Initwithinteger:0];    }     return Self ;}

The subclass of Custom is customsub and is implemented as follows

- init {    = [Super init];     if (self) {    }    return to self ;}

Also overrides the parent class count property accessor

-(NSNumber *) count{//custom ...}

-(void) SetCount: (NSNumber *) number{   //Custom ... .. }

When you initialize the subclass

Self = [super init];  It will call Init from NSObject->custom->customsub to initialize the current class member separately, and your subclass overrides the custom property accessor, then it will affect custom to initialize its own member count.

This is a design pattern in which subclasses should not affect the parent class to initialize their own members. This can cause other problems.

If we write this down, it may not be a problem. Then I want to be bad, that ... You know..

So we should  use _count to directly access properties in init or Dealloc  . The above problem does not occur.

Using Self.count in Dealloc

----------It is possible that Count's life cycle has ended and no longer accepts messages--------

The above is copied from other articles, I do not quite understand what is the case, it should be said that a nil object to send Releas message will not have a problem.

I personally understand: in fact, Init, dealloc do not recommend the use of accessors and direct use of _property root cause is

Subclasses should not be able to influence the parent class to initialize and release their own resources (property) "By the result of the child class overrides the parent class attribute accessor," the use of _property can effectively avoid some unknown errors.

Reference: http://stackoverflow.com/questions/8056188/should-i-refer-to-self-property-in-the-init-method-with-arc/8056260#8056260

http://fann.im/blog/2012/08/14/dont-use-accessor-methods-in-init-and-dealloc/

2, why [Super Dealloc]; To the last

-(void) dealloc {//custom release self source     [Super Dealloc]}

The memory of the freed class is defined in NSObject, and the order of release should be

First release the source in this class, and call the Dealloc in the parent class. It should be possible to have more than one parent class in this class, along the inheritance chain

Releases the resources in the parent class in turn.

This process, in contrast to the INIT process,

-(ID) init{   = [Super init];    if (self) {    //custom init   }    }

About Dealloc Precautions