2013-03-23 56 views
2

我有一個類需要在構造器中傳遞不同數量的Func委託。這些代表中的每一個都將指向一個不同的函數,每個函數具有不同的返回類型,並且具有不同數量的參數(類型爲double)。這些函數中的每一個都將被相應地調用。具有不同返回類型和參數數量的Func委託的列表

問題1.現在,爲了讓那些使用這個類的人變得更容易,我想讓用戶通過Func委託人的List<object>。這是否可能,並且如果是的話,我能夠確定返回類型和每個Func所需的參數數量,方法是將List<object>傳遞給(即構造函數)的方法?

問題2.如果上述不可行,我是否需要用每種不同的返回類型/參數數量的不同組合來重載構造函數,並相應地路由每個Func -_-如果沒有人可以指向我正確的方向,我覺得我在錯誤的方式處理這個...

注 - 從蟒蛇背景的,我會做這樣的事情(我在C#中缺乏經驗):

import inspect 
def test(x): return x 
inspect.getargspec(test) 

returns: ArgSpec(args=['x'], varargs=None, keywords=None, defaults=None) 

非常感謝

+1

你的設計將很多fun​​cs傳遞給一個類是不尋常的。您是否考慮過爲每個想要通過的func定義一個虛擬方法的類,並讓用戶重寫這些方法? – dtb 2013-03-23 21:14:14

+1

您:_am我能夠確定每個Func_所需的參數的返回類型和數量。因爲所有'Func'類型都是從'System.Delegate'派生的,所以您可以使用'List '來代替使用'List '。然後如果'd'是'List '的一個元素,你可以使用'd.Method.ReturnType'和'd.Method.GetParameters()'來獲得你要求的信息。你可以用'd.DynamicInvoke'調用委託。 – 2013-03-23 22:21:49

+0

Jeppe非常感謝 – Sherlock 2013-03-23 22:40:56

回答

6

問題1.現在,爲了讓那些使用這個類的人更容易,我想讓用戶傳遞一個Func委託列表。這是否可能,如果是的話,我能夠確定List傳遞到的方法(即構造函數)中每個Func所需的返回類型和參數個數?

不是。你可以讓一個List<Delegate>(或其他徵收與Delegate元素類型),但沒有Func特異性,原因有二:

  • Func實際上是一個類型的家庭,用不同數量的通用類型參數。就CLR而言,這些類型完全分開; Func<TResult>Func<T, TResult>Action<T>EventHandler不同。

  • 即使您只處理相同通用類型委託的多個值,但它們可能具有不同類型參數的事實意味着它們與CLR的類型不同;沒有辦法說List<Func<>>「可能有不同類型參數的函數列表」。 CLR再次將它們視爲不同的類型 - 儘管這次至少有一個具有通用的泛型類型定義。

問題2:如果以上是不可行的,我將需要返回類型/ PARAMS的數量和路線的每個不同組合重載構造每個函數功能相應

嗯,有幾個選項:

  • 讓所有的參數可選,給他們每個人的null默認值,然後調用構造函數時使用命名參數:

    var foo = new Foo(clickHandler:() => ..., 
            keyHandler: key => ...); 
    
  • 克雷亞德建築商,使各種功能,可設置爲屬性 - 這個作品非常好,對象初始化語法:

    var foo = new Foo.Builder { 
           ClickHandler =() => ..., 
           KeyHandler =() => ... 
          }.Build(); 
    

後兩個解決方案,取決於你真的有一個特定的命名的目的,當然。

如果你可以更清楚地瞭解你想達到的目標,這將有所幫助 - 正如dtb所說,多態性可能在這裏更合適。您可以創建一個抽象類,其中不包含虛擬方法的實現,並且實現可以選擇要覆蓋哪些類。

+0

謝謝Jon。我想我會沿着使參數可選的路線走下去。只是要清楚 - 我可以將代表放入對象列表中,然後傳遞給構造函數?如果我能做到這一點,是否有類似於Python的inspect.getargspec方法的功能?再次感謝你的幫助。 – Sherlock 2013-03-23 21:32:18

+1

@Sherlock:不會有任何拳擊參與;代表已經是參考類型。你可以將它們全部轉換爲'Delegate',但它可能會很麻煩。我懷疑你仍然在過多地考慮你將在Python中做什麼 - 慣用的C#通常是非常不同的,對於任何給定問題的最新解決方案在C#中可能與Python中同樣問題的最新解決方案完全不同。 – 2013-03-23 21:36:55

相關問題