一般來說，當某乙個物件有多個集合型別的子元素時，我們都會給每個子元素建立乙個集合物件來承載子元素，類似於：
public一般來說，這是沒什麼問題的。但是某些情況下，例如在圖形化與結構化文件之間進行轉化時，這樣做有很多弊端。如圖：class
process
圖中：participant1，展現型別為
pooldiagram
，對應模型為之前的
process
物件；
task1，展現型別為
usertaskdiagram
，對應模型為
usertask；
task2，展現型別為
manualtaskdiagram
，對應模型為
manualtask
我們每向participant1
中增加乙個
usertaskdiagram
或者manualtaskdiagram
時，都需要向對應的
process
中增加usertask
或者manualtask
物件；刪除時也是如此。這時候就需要通過判斷圖形的型別來向相關的模型列表中增加模型物件，刪除也需要判斷。在型別比較少的時候，這樣做比較簡單，但是如果型別比較多的時候，特別是型別數量是乙個變化點的時候，這種處理方式侷限性就很大了，每次變動，都會對既有的**造成影響。具體的**可能類似於：
增加：if(diagram is usertaskdiagram) process.usertasklist.add(usertask)
else if(diagram is manualtaskdiagram)process.manualtaskdiagram.add（
manualtask）
......
......
刪除：if(diagram is usertaskdiagram) process.usertasklist.remove(usertask)
else if(diagram is manualtaskdiagram)process.manualtaskdiagram.remove（
manualtask）
......
......
即使我們將這段**封裝到乙個地方，這個地方在新型別增加時也需要改變，有沒有一種方法可以在型別增加時不改變既有**呢？答案是肯定的。
具體方案如下：
public上面的**將所有的型別列表相關的操作封裝在containerelement中，該類維護乙個型別和物件集合的對映關係，從而將相關的判斷邏輯從**中去除。再增加或者去除新型別時我們的process類是保持不變的，相關的增加刪除邏輯也會儲存相對固定。class
containerelement
public
function removechildelement(element:bpmnelement):
void}}
public
function getchildelements(classinfo:class):arraycollection
}public
class
process extends containerelement
public
function
gettype():class
}
經過以上實現，之前的增加刪除邏輯變為：
process.addchildelement(usertask);
process.removechildelement(manualtask);
去除物件中的型別集合
一般來說，當某乙個物件有多個集合型別的子元素時，我們都會給每個子元素建立乙個集合物件來承載子元素，類似於 public class process 一般來說，這是沒什麼問題的。但是某些情況下，例如在圖形化與結構化文件之間進行轉化時，這樣做有很多弊端。如圖 圖中 participant1，展現型別為 ...
list集合去除重複物件
物件重複是指物件裡面的變數的值都相等，並不定是位址。list集合儲存的型別是基礎型別還比較好辦，直接把list集合轉換成set集合就會自動去除。當set集合儲存的是物件型別時，就需要在物件的實體類裡面重寫public boolean equals object obj 和 public int ha...
ArrayList去除集合中自定義物件元素的重複值
需求 arraylist去除集合中自定義物件元素的重複值 物件的成員變數值相同 b 注意事項 重寫equals 方法的 contains方法判斷是否包含,底層依賴的是equals方法 remove方法判斷是否刪除,底層依賴的是equals方法 public class demo2 arraylist...