→ m339606: 看不是很懂...你要的不就是泛型嗎? 11/25 19:17
不只是泛型，還要委派，而且外部只能提供委派，實際執行是在內部，所以比較像事件
委派還做得到，但泛型要加上去就會限制類別的型別
我想做的事情舉例來說
假設我是家具設計公司，然後我有一間跟我長期合作的木材加工廠
我手上有好多個案子在進行，每個案子都可能含有桌子、椅子、櫃子等家具
今天第一個案子含五件家具，桌子一張，椅子兩件，櫃子兩件
其中桌子，一件椅子和一件櫃子都用我們設計好的現成外型去製作就好
但是有一件椅子和一件櫃子客戶有要求客製化，椅子要客製化圖案，櫃子要多隔一層
我送了五個設計圖過去木材加工廠，其中有三件照設計圖做就好
但有兩件除了原本的設計圖，還加上客製化說明調整部分的文件
然後我們公司等著收貨就好，實際執行家具製造都是加工廠的事
委派就是客製化文件說明客製化內容和步驟
泛型就是客製化處理時需要的材料和成果
決定泛型會卡住就在於，如果我決定客製化文件泛型是為椅子而作而且輸入楓木
那麼我那批家具(List)就只能全部都是用楓木做椅子 class 家具製造<楓木, 椅子>{}
因為宣告List限制該類別泛型對象要一致
var 第一批訂單 = new List<家具製造<楓木, 椅子>>()
但我有可能會需要 家具製造<漂流木, 椅子> 或 家具製造<違法檜木, 鞋櫃>
這樣就無法作為List宣告了
經過網友來信討論
目前是使用 public Func<T, object> 客製化{ get; set;} 來應對固定型別要求
然後用List<家具製造<第一批訂單材料, object>>()來宣告
訂單材料就包含楓木、漂流木、違法檜木的內容，依照每次訂單不同而改變
輸出就自己轉型，將其定義寫成enum作為另外一個屬性來確定轉型後是椅子還是櫃子
雖然不是原本想像中的做法，至少目前可以運作
感謝網友幫忙
→ pauliaia: Chain-of-responsibility pattern 是這個嗎 11/26 01:41
→ pauliaia: 這是把switch case 拆出來寫的一種方法 基本上多類型別 11/26 01:41
→ pauliaia: 簡單的方法就是用if（物件判斷）c sharp我也很菜 11/26 01:43
我查了一下這方法
這跟我想要的作法不太一樣耶
因為他還是只能宣告幾個固定的操作方式
或是變成每個呼叫端都要寫很多方法作繼承，比較不合我的需求
比較希望用簡單的賦值方式讓呼叫端操作
不過學到新方法了，原來還有這種做法，感謝提供訊息
※ 編輯: Peruheru (220.134.18.8), 11/26/2015 16:03:21
推 m339606: Sorry..你的舉例我看了三次還是不太明白 11/26 21:05
→ m339606: 直覺是要用interface來處理 11/26 21:05
→ bantime: 樓上..原PO的東西我有跟他要code來看..感覺上interface 11/26 21:57
→ bantime: 還是不行..因為也沒有很完整的敘述 不然也許設計上可以改 11/26 21:57
→ bantime: 因為我比較好奇return出來的東西要做什麼,有沒有可能 11/26 21:58
→ bantime: 在callback裡面處理這樣 11/26 21:58
→ Peruheru: 好吧我舉例難懂 囧 11/26 22:19
我的類別是寫給其他寫程式的人使用的工具
但是使用者程度有高有低
沒辦法要求大家都要懂繼承、介面的做法
委派是因為這個工具類別有部分資料需要特別處理過
像是有的地方需要拆解字串轉換後才是實際可以繼續處理的東西
有的地方則是需要將字串依照規則轉為日期格式後繼續處理
每個呼叫處都略有不同，沒辦法事先寫好所有處理方式(而且還會再修改、增加)
介面和繼承理論上可以達成類似效果，但是這會增加呼叫這個類別的難度
我寫的類別除了委派要使用者自己決定以外，其他都是類別內自己完成並傳送結果
我希望使用者只要知道"我丟物件陣列和描述資料進去後，沒出錯就是完成了"就好
而不要讓使用的人需要做太多事才能完成
所以介面和繼承對我來說是下選
因為這類別主要不是寫給我用的，我得顧及其他人撰寫時的難易度
將類別當成一個元件或控制項，給他資料給他事件然後看他表演就好
感覺上是最容易讓使用者上手的做法
大概是這樣
※ 編輯: Peruheru (114.36.227.162), 11/26/2015 22:44:57
推 m339606: 不如你直接把你要想要的結果用Code表示(不用可編譯) 11/26 22:49
→ m339606: 或是用流程圖的方式來說明... 11/26 22:50
※ 編輯: Peruheru (114.36.227.162), 11/26/2015 23:34:24
推 Litfal: 如果要讓使用者簡單使用，為什麼不考慮用工廠隱藏介面建立 11/26 23:35
→ Litfal: 細節？ 11/26 23:35
→ Peruheru: 我馬上去惡補工廠模式... 11/26 23:44
→ bantime: 我是覺得工廠模式也不會是你需要的@@ 11/27 00:06
→ bantime: 不然就是我沒想到適合的方式.. 11/27 00:06
→ Peruheru: 如果我沒搞錯工廠模式的做法，他所隱藏的細節仍然是我希 12/01 10:55
→ Peruheru: 望使用者可以自訂的地方，如同前面提到我並不能針對細節 12/01 10:56
→ Peruheru: 事先決定做法，因為每個呼叫者作法可能有細微不同處 12/01 10:56
→ Peruheru: 所以我的類別應該無法適用工廠方法 12/01 10:57