1樓：趙華華
輪子哥的例子有getParent合理，因為UI是樹狀結構。
遊戲buff是單層結構，而且一般buff很有可能互相有影響，還會因為角色狀態不同又有不同影響。如果邏輯都寫在buff裡，難免不會發生每個buff要必須知道其他buff的實現的情況。更好的辦法是每個buff只保留剩餘時間之類的最基本實現，buff互相作用的最後計算通過乙個stateManager來實現。
這樣可以更好的解耦。
不知道這個算不算設計模式，比較似組合模式和策略模式的混合。
2樓：天象
最少知道原則是有意義的。比如，當你需要把乙個底層類的所有者改為另乙個上層類的時候，假如你在底層類裡保留了上層類的引用parent，就需要手動修改這個引用，增加了耦合。同時，如果你其實在對某個類的大部分行為裡都不需要知道上層類的資訊（從另乙個方面說，這也首先反映了這兩個類的設計的解耦），那麼你就不需要加parent引用。
總之，架構設計沒有一定之規，根據具體需求進行適當的解耦正是軟體工程藝術性的體現。
而針對這個具體的問題，你是否需要乙個parent，取決於你具體的遊戲系統設計。我認為，大部分情況下你是不需要加這個parent的。
1)如果設計的是乙個正常，簡單的buff體系，buff效果跟角色沒有關係，buff持續時間跟buff本身沒有關係，那麼buff內加parent其實是沒有意義的。比如你要改變buff的時間，不會因為buff加在不同的角色上而需要改變不同的時間，也就沒有必要訪問parent。少數需要同時訪問的邏輯，可以用tuple解決。
2)如果設計的是乙個非常複雜的體系，buff效果，buff時間，角色屬性，buff屬性之間都會互相影響，那在這種地方解耦也沒有意義了，反正你是需要把所有的邏輯都寫在一起的。你就不可能有「改變buff時間」這種簡單的操作了，實際上這個操作本身的條件已經跟所有結構耦合了。當然你也不可能把這個邏輯寫的太複雜，玩家吃不消。
3)如果你的體系很奇葩，恰好在這個地方需要耦合……那就加parent吧。
層次混亂不重要，實際上character和buff肯定不管你怎麼寫都是平級的。只有抽象層和繼承樹需要保持嚴格的層級關係，網狀邏輯很常見。標頭檔案包含是日經問題了，#program once解決。
3樓：fantiny
你的描述混亂，其實說了幾個不同的問題。
解決你說的一系列問題有下面幾種方式。
1.visitor模式
2.事件訊息傳遞解耦
3.IOC介面翻轉
亞馬遜fbm鋪貨模式每天最少鋪多少貨？
跨境電商monster 像現在的話一般做的是精鋪模式，每天只需要上傳10到20件商品就可以了，然後如果是正常鋪貨的話，有一點經驗之後可以鋪100到200件商品，後期做熟了之後就可以上傳300到400件商品 Lucy 亞馬遜的鋪貨也不是無腦的，就如你說的通過鋪貨然後選出幾個 明星產品 進行精細化經營來...
最好的設計是最少的設計，怎麼理解這句話？
那個少年 在世界現代設計史上，這句話可以算很有歷史了。不是最早但里程碑式的提出應該是德國建築設計師，Ludwig Mies Van der Rohe 公尺斯 凡德羅 它曾提出 Less is more 少則多 設計史研究者把這類設計思想指導下的運動或思潮概括為 功能主義 或 現代主義 設計。起初是反...
為什麼韋德沒有巨星哨是球星中最少的？
體毛哨 是諷刺裁判為維護聯盟利益偏袒一方，出現的不公平判罰。始自2006年NBA總決賽上裁判對邁阿密熱隊韋德的爭議性吹罰。nba的巨星偶像，代表了聯盟形象的，為了保護他們不受傷或者惡意犯規，為了造神，維護聯盟商業利益，哨子在他們身上總有偏向性的，有時到了一碰就犯規的程度。這種哨子超過了明星哨的範圍，...