1樓：樓主別編故事裝逼了
這是乙個非常麻煩的問題。
item和parker生命週期不一樣，誰先死亡？？
多執行緒下會非常麻煩，用shared_ptr和weak_ptr可以勉強解決一下。
2樓：flashyiyi
補充下，destroy和drop是兩個不同的操作，drop的時候不一定destory，因為有可能會放入另乙個容器，所以drop方法必須單獨存在不管放在哪。
但destroy確實必須drop，所以可以在前面檢查一次自動呼叫，或者沒有drop直接報錯（推薦）
至於方法放哪？只有乙個肯定放父容器。邏輯則是操作誰就放誰那，盡量別混在一起，一定要偷懶就混子級。
其實老老實實把drop和destory分開就沒這事了，多一次呼叫怎麼了？
unity的容器就是因為非要把兩者綁一起搞出很多奇怪的東西，尤其是scene那塊……現在都沒修改的打算。
另外，drop得做成延遲的，否則很容易出現遍歷時同時修改陣列的問題。
3樓：
換個思路，item就是item，揹包就是揹包，只儲存自身屬性。改變物件屬性的行為做成乙個頂級函式，item和揹包都只是入參而已。揹包和item的關係可以另外存也可以存一邊，頂級函式知道往哪操作就好了。
如果非得搞物件，現實中拿出某個物品或者銷毀某個物品應該是人（或其他）的能力，而不是item或者揹包的能力。所以要不要考慮再加個類？
4樓：someone
「他說有時候Item不在揹包中，而在場景中，那麼當像銷毀場景中的Item難道要去在Area中再寫個Destroy(Item)。」
item都到其他場景了，從揹包到其他場景的時候（拿出來）就應該改變weight了，難道拿出來後背包還是原來那麼重的嗎。。
5樓：joker
他說有時候Item不在揹包中，而在場景中
相比於健壯性以及耦合性，我更認為這句話的問題更大。
首先看的出來這個幾乎就是個unity中的遊戲邏輯，處理的就是幾乎什麼遊戲裡都有的揹包系統。而這個盧森堡老哥的意思很明確——他想要做通用設計。從而讓Item這個類成為通用設計，場景中的掉落物品以及揹包中都能通用。
但這麼設計顯然是不正確的，因為packer並不需要持有item相關的操作，這地方就顯得很冗餘。
正確的做法應該是，將Item拆分為DropItem（controller），PackerItem（controller）以及ItemInfo（model），
packer持有PackerItem（用於專門處理揹包的資料顯示以及與揹包的互動），每當物體要被撿起的時候直接通過訊息中心傳送自身的model給揹包做儲存即可，而揹包中的PackerItem應該都直接由當前儲存的ItemInfo資料去生成以及管理。
如此一來，物品這一資料結構得到了復用，同時這麼做在後期做儲存揹包資料的時候都會方便很多。
6樓：熊起
既然Drop事件同時和Packer和Item兩個型別有關，就不適合封裝到其中乙個型別內部。
建議作為乙個靜態方法。
另外我覺得遊戲邏輯這種注定暴露給玩家的東西，未必適合封裝，switch(type)之類看起來low的辦法不一定就不好
7樓：holy
這個設計顯然違反自然規律，揹包的重量不受主觀的增加減少而改變，只受裡面的item數量，所以應該把weight設計為乙個get屬性或者方法，
設計一定是參照業務規則來完成的，而【自然規律】是第一規則，當你覺得有問題的時候，想想是否符合自然規律
8樓：modour
揹包應該只有加入和取出物品的能力，其重量應是揹包中各物品重量的求和。
物品銷毀，看介紹應該是消耗的意思吧。
揹包中物品的消耗，應該是先從揹包中取出，然後再消耗。揹包中物品少了，其重量求的和也就小了。物品完全不用知道揹包的存在。
物品的消耗，根據物質不滅，物品不是消失了，而是變成了其他的形式繼續存在。因此，物品消耗只是物品從可消耗狀態變成了消耗後的狀態。
現在，物品很簡單，只保有自身重量和是否已消耗的狀態;揹包很簡單，只管放入和取出;物品消耗很簡單，只是改下物品的狀態;揹包中物品的消耗也很簡單，只是取出，然後消耗。
9樓：Xi Yang
反著直接操作容器的屬性，在設計上也不是不可以。比如intrusive list，甚至成員就是容器，每個成員銷毀的時候會自動把自己前後接起來。
但是不能搞成題目這樣裸奔，要特化、限制。比如寫個PackageItem型別，專門用於被放入包裹、析構時自動執行出包裹操作，然後藥水繼承它、裝備繼承它，等等。
10樓：
destroy確實是item裡的乙個方法，但是不該動packer的weight
使用物品那就給packer增加use方法啊，裡面減去重量，移除，然後呼叫destroy
item就是item，理論上甚至不應該裡面存packer，當然就不該呼叫他裡面的東西，item對其他東西有影響只能通過事件或者廣播這種機制
遵循本質，該是誰的事情就是誰的事情
11樓：
這個設計有點問題，但如果類層次規模不大的話也沒某些人說的那麼誇張，就當緊耦合來處理就是了。
，一般如果真要這麼「偷懶」的話，我會明確一下item的介面，比如PackedItem，然後在基礎類中實現類似的功能，至於是類成員還是方法暴露只是細枝末節的事。
也有人提到事件，那當然是更好的解耦方式，就看用不用得著了。
12樓：lymim lee
Packer 中的 Item 能夠訪問並直接修改Packer 的關鍵屬性。
這種邏輯很神奇，就相當於：
作為支付寶的使用者，我把錢存在支付寶了，就要求支付寶把它整個公司的賬本對我公開。然後我每用一筆錢的時候，自己去更新支付寶的公司賬本。
13樓：用心閣
不清楚Item.Destroy() 本身的語義是什麼。但是這個寫法不符合OOP的設計原則。
Destroy可以有兩種實現邏輯
當parent不為空時，丟擲Illegal State Exception，也就是說乙個在揹包中的Item不能被銷毀。
當parent不為空時，呼叫parent的Drop() 方法，也就是說，銷毀乙個揹包中的Item意味著先從揹包裡移除，至於揹包的Drop() 方法怎麼減weight是揹包類的內部邏輯，也許揹包類內部還維持其他狀態，比如體積和價值，也許揹包還維持Item的weight之和與計數，這些都不是Item的business了。
14樓：禽牙
理解沒錯的話，drop是item被移出到包裹外，destroy是item被用掉。那麼destroy掉乙個item就意味著item被移出包裹，說起來不是該在Destroy裡面呼叫pack.drop(this)方法嗎？
如果item不一定在包裹裡，呼叫drop前應該會有pack是否有效的判斷
15樓：Mistery
銷毀的時候這麼寫就好了
item.packer?.drop(item);
item.destory();
packer裡的weight可以寫成items.sum(i=>i.weight)
16樓：天天
如果item 可以直接 destroy ，而不是先pick再destroy的話，那麼destroy應該是item的方法。
應該在item中設計事件 destroyed ，在packer 中訂閱item destroyed 事件並更改weight
17樓：AWP996
item還要知道packer的weight這麼細節的東西，明顯是有問題的。而且packer的destroy和item的destroy的含義也應該是不同的，能先澄清packer和item的destroy含義麼？
是否存在某種材料，可以改變光的波長？
則也 光波在任何一種介質中波長都要相應改變的，普通玻璃折射率大於1.5，所有真空中波長折射進入後，波長縮短為真空中為 2 3 0.6 按照我的理解，正確問題是 是否存在某種材料，可以改表入射光的頻率？這是個非常有意義的問題，雷射出現後的1961年，P.A.弗蘭肯等人首次利用石英晶體將紅寶石雷射器發出...
UI設計 也做web前端 對以後發展是否有利？
建議主修乙個職業，輔修另外乙個技能，UI或者前端，公司的崗位體系，注定是崗位細分，特別是設計 前端，橫跨兩個職能部門，去稍微大的公司就不討好了，因為雖然兩個都會，但是可能投入時間的切分，導致不能拔尖，同時公司也會對你的定位不太清晰。那為什麼建議輔修另乙個技能呢？當然是不同技能組合帶來的非職場收益，比...
是否存在 發現沒有恆星的孤立類地行星？
恆星產生就是氣體雲慢慢聚集起來。達到臨界點開始反應就是了。然而氣體雲不夠怎麼辦？流浪行星就是咯。也可能是類木的，也可能是類地的。 fgxh 您說的這種星球是很可能存在的，但以現在的技術手段很難發現，因為孤立的行星就意味著自身不發光也無法反射其他天體的光線 電磁波 所以即使我們有再強大的望遠鏡也難以直...