1徘钥、實(shí)例init方法
When I explained why I used variables instead of properties in the init method, I mentioned the gotcha of accidentally adding side effects if they provided implementations of those methods. However, another potential gotcha I didn’t mention is if someone subclasses your class, overrides the setter for your property, and adds a side effect, you have the same problem.
新建一個(gè)類，使用variables創(chuàng)建而不是使用properties創(chuàng)建init方法析校，一是因?yàn)槿绻擃愄峁┝诉@些方法的實(shí)現(xiàn)（implementations），可能會產(chǎn)生副作用垃它，比如在其它地方通過屬性修改了變量的值迁霎。二是因?yàn)椋绻麆e人繼承了你的類俺陋，并重寫了setter方法修改了你創(chuàng)建的屬性豁延，也是會產(chǎn)生潛在問題的。
二腊状、對象釋放須知
- (void)dealloc {
[_sushiTypes release];
_sushiTypes = nil;
[super dealloc];
}
Remember that when you created the array with alloc/init, it had a retain count of 1. So when you’re done with the array, you need to decrement the retain count. In Objective-C, you can do this by calling release on the object.
But where should you release it? Well, you should definitely release the array in dealloc, because obviously when this object is deallocated it will no longer need the array. Also, whenever you create an object in viewDidLoad (setting the reference count to 1), you should release the object in viewDidUnload. Don’t worry too much about this for now – some day I might write a separate memory management tutorial on that subject.
注意：
Note that you also set the object to nil afterwards. This is a good practice, because by setting it to nil it avoids a lot of problems. Any time you call a method on a nil object, it does nothing, but if you don’t set it to nil, if you tried calling a method on a deallocated object your program should crash.
三诱咏、Objective-C Cheat Sheet and Quick Reference
