Callbacks and object ownership

With all of these callbacks, there is a danger that objects waiting for the callbacks might not get deallocated correctly. Thus, it was decided that:

  • Notification centers do not own their observers. If an object is an observer, it will typically remove itself from the notification center in its dealloc method:

    -​ ​(​v​o​i​d​)​d​e​a​l​l​o​c​
    {​
     ​ ​ ​ ​[​[​N​S​N​o​t​i​f​i​c​a​t​i​o​n​C​e​n​t​e​r​ ​d​e​f​a​u​l​t​C​e​n​t​e​r​]​ ​r​e​m​o​v​e​O​b​s​e​r​v​e​r​:​s​e​l​f​]​;​
    }​
    
  • Objects do not own their delegates or data sources. If you create an object that is a delegate or data source, your object should excuse itself in its dealloc method:

    -​ ​(​v​o​i​d​)​d​e​a​l​l​o​c​
    {​
     ​ ​ ​ ​[​w​i​n​d​o​w​T​h​a​t​B​o​s​s​e​s​M​e​A​r​o​u​n​d​ ​s​e​t​D​e​l​e​g​a​t​e​:​n​i​l​]​;​
     ​ ​ ​ ​[​t​a​b​l​e​V​i​e​w​T​h​a​t​B​e​g​s​F​o​r​D​a​t​a​ ​s​e​t​D​a​t​a​S​o​u​r​c​e​:​n​i​l​]​;​
    }​
    
  • Objects do not own their targets. If you create an object that is a target, your object should zero the target pointer in its dealloc method:

    -​ ​(​v​o​i​d​)​d​e​a​l​l​o​c​
    {​
     ​ ​ ​ ​[​b​u​t​t​o​n​T​h​a​t​K​e​e​p​s​S​e​n​d​i​n​g​M​e​M​e​s​s​a​g​e​s​ ​s​e​t​T​a​r​g​e​t​:​n​i​l​]​;​
    }​
    

None of these issues exist in this program because your Logger object will not be deallocated before the program terminates. (Also, in a bit of a fluke, in this exercise I used two well-documented exceptions to the rules: an NSURLConnection owns its delegate and an NSTimer owns its target.)

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset