在我们的class中设计delegate的时候，我们通常会有几个注意事项。
假设我的class叫做MyClass，那我们可能会有定义一个MyClassDelegate这个protocol当作我的delegate protocol。
而MyClass中我们可能是这样写。
@protocol MyClassDelegate <NSObject>
- (void) myClassOnSomeEvent:(MyClass*)myClass;
@end
@interface MyClass
{
id<MyClassDelegate> _delegate;
}
@property (nonatomic, assign) delegate;
@end
上面的code我们注意到delegate此property是定义为@property (assign)。
为什么我们不用retain而要用assign呢?
原因就是在于iOS的reference counting的环境中，我们必须解决circular count的问题。
让我们来写写我们平常都怎么用delegate的，下面的code我想大家应该不陌生
- (void)someAction
{
myClass = [MyClass new];
myClass.delegate = self;
....
}
这边很快的就出现circular reference了
假设上面的code是写在一个myViewController的物件当中，
之后一旦myViewController的reference count变成1的时候，
myViewController跟myClass这两个兄弟两只剩下互相retain，那就变成了孤岛，也就因此造成了memory leak!!! 
也因为这样，iOS官方文件才会要建议我们所以的delegate都要用assign property。
也就是所谓"weak reference"的property，他的特色就是虽然会持有对方的reference，但是不会增加retain count。
如此下来，当myViewController的retain count变成0，则会dealloc。
同时在dealloc中，也一并把myClass release，则myClass也跟着被release。
- (void)dealloc
{
[myClass release];
[super dealloc];
} 
事情就结束了吗? 还没有唷...
这边还有一个大家常常忘记的重点，那就是上面的dealloc这样写会有潜在危险。
应该要改成这样
- (void)dealloc
{
myClass.delegate = nil;
[myClass release];
[super dealloc];
}
你可能会很纳闷，myClass不是马上就会被release了吗? 干嘛要先把他的delegate设成nil?
那是因为我们假设myClass会马上会被dealloc，但是现实状况这个是不一定的，
有可能里面内部有建个NSURLConnection，或是正在做某件事情而让其他物件也retain myClass。
如果myClass没有马上dealloc，那他的myClass.delegate不就正指向一个不合法的位置了吗? (此种pointer称作dangling pointer野指针) 
解决方法是在MyViewController的dealloc中，在release myClass之前，
要先把原本指向自己的delegate改设成nil，这样才可以避免crash发生。
在我之前写的project，很大一部份的crash都是这样造成的，因为这个问题通常不是每次都发生，
但是发生的时候确很难在重新复制，所以不可不慎啊。 
但是很兴奋的是到了iOS5中的Automatic Reference Counting 这个问题可以有所改善。
在ARC中提出了一个新的weak reference的概念来取代原本的assign，
weak reference指到的物件若是已经因retain count归零而dealloc了，则此weak reference也自动设成nil。
而原本旧的这种assign的作法，在ARC中叫做__unsafe_unretained，这只是为了相容iOS4以下的版本。
回顾重点:
1.如果你是写library给别人用的，记得把你的delegate设成assign property，这样才不会造成circular reference
2.当你是要始用别人的library，记得在你自己dealloc的时候，把delegate设成nil，以避免crash的事情发生。
