在我編程的遊戲中,我爲遊戲中的所有實體使用了一個複合對象。這些實體由組成對象組成,這些對象定義了諸如健康或運動等小功能塊。NSNotifications的最佳實踐
我的問題是:
它是確定後從組件的通知,但引用其父實體發送通知,而不是對象?
我很想做到這一點,因爲向實體添加觀察者更容易,而不是在實體內部找到正確的組件。
我被告知不應該發佈另一個對象的通知。
有什麼優點和缺點?
在我編程的遊戲中,我爲遊戲中的所有實體使用了一個複合對象。這些實體由組成對象組成,這些對象定義了諸如健康或運動等小功能塊。NSNotifications的最佳實踐
我的問題是:
它是確定後從組件的通知,但引用其父實體發送通知,而不是對象?
我很想做到這一點,因爲向實體添加觀察者更容易,而不是在實體內部找到正確的組件。
我被告知不應該發佈另一個對象的通知。
有什麼優點和缺點?
通常你會想到一個通知來自「來自」一個對象。因此,如果您正在調試並且想要查找通知的來源,那麼您需要查找該對象本身的代碼。
違反這種期望並非違法,但當他們不得不更努力地尋找通知的真實來源時,它可能會讓某人詛咒你。另外,如果您有許多單獨的組件都會發布通知,但如果您想要更改通知(例如,其中的userInfo),則可能會更難以重構代碼。
如果你能保證你的組件始終有一個有效的指針到其父,最好的辦法是讓組件要求其父張貼通知:
@implementation ComponentA
- (void)someMethod
{
[self.parent pleasePostSomethingChangedNotification];
}
@end
@implementation Parent
- (void)pleasePostSomethingChangedNotification
{
// Parent may post the notification immediately,
// or may selectively post the notification based on some other condition,
// or post it later on after coalescing changes from several components,
// or ...
}
@end
我的健康組件在健康狀況達到零時發佈通知。如果我按照你的建議轉發它,即使沒有健康成分,父母也總是會有一種方法。 – 2012-04-09 00:40:06
那麼,如果它對你的情況沒有意義,不要那樣做!這是一個可能的方式來做到這一點,而不是一個要求的建議。 – 2012-04-09 00:41:44
也許再冒充從一個問題凝聚力的觀點比較好。也就是說,觀察者是在看複合物還是細粒物體?例如,當健康狀況達到零時,複合對象上的高級別(死亡事件)不是事件嗎? – Fuhrmanator 2012-04-10 20:58:09