關於父母/孩子互動的面向對象設計偏好

Question

我正在研究一種音樂工作人員類（CCNode）和音符類（CCSprite）的音樂符號應用程序。

注意添加到音樂的工作人員，如：

// MusicStaff.m 
[self addChild:note]; 

注意事項有一個粒子發射器，這需要被添加到父..我認爲做這樣的事情：

// Note.m 
[self.musicStaff addChild:self.emitter]; 

並不酷，因爲我不喜歡控制員工的筆記的想法---我喜歡將員工視爲控制其擁有的孩子的人員。

我真的覺得這個粒子發射器應該是Note的孩子，因爲它在技術上是音符的一部分，而不是音樂人員的一部分 - 所以將它添加到音樂人員本質上感覺不對。但是，根據我對cocos2d的瞭解，雖然可以將子元素添加到CCSprite，但子元素不管理子元素的繪製，因此此粒子發射器不可見。

這就是說，因爲據我所知，去了解這是發射器添加到員工的唯一途徑，我寧願做：

// MusicStaff.m 
[self addChild:note]; 
[self addChild:note.emitter]; 

然而，在我的項目團隊成員感覺這是「倒退」和「啞」，並且該筆記應該將發射器直接添加到其母公司。我只是尋求一些反饋，如果我的想法是真的「倒退」和「啞」，或者如果我有一個有效的點...

另外我很好奇，如果有另一種方法來解決這個問題，發射器直接註釋並使其以某種方式吸引其子女？

Answer 1

就面向對象的設計而言，如果Emitter是由它的父對象創建的，我認爲它不應該將它自己添加到Staff中。如果有人要與工作人員談話，讓它成爲它的直接孩子，注意。更好的是，讓Note對工作人員提出的問題做出迴應，所以最後工作人員控制着要顯示的內容。

Answer 2

您可以將粒子添加爲精靈的子節點並將它們繪製。無論資源如何讓你意識到子節點沒有被繪製是錯誤的。

我認爲你可能誤解了sprite batching的問題。在這種情況下，當您使用CCSpriteBatchNode時，只能將CCSprite對象添加到批處理節點和批處理節點的子節點。因此，在這種情況下，試圖添加一個粒子效果或任何其他節點作爲精靈分批精靈的子節點會導致cocos2d中的斷言，告訴您這是非法的。

至於「愚蠢問題」：這兩種選擇都不是真正的愚蠢，但是向父母添加發射器具有次要好處，因爲該筆記控制了筆記的內在責任：管理筆記的壽命粒子效應。