2009-09-07 174 views
4

我喜歡創建一個將從方法傳遞給方法的數據列表,但是我不能使用結構,因爲包含在這個列表中的數據將根據輸入而變化。不同類型的列表?

例如

if (x == 1) { 
    a = 1 
    b = true 
    c = 42 
    d = "hello" 
} 

if (x == 2) { 
    a = 2 
    b = 'g' 
    c = "sup" 
} 

我相信我的選擇是這樣的:

  1. 創建一個字符串數組或列表,並且投中的數據回到它原來是從字符串。這很麻煩,可能會導致無法解釋的輸入錯誤,但不會太糟糕,因爲它在運行時都會被檢測到。
  2. 爲每種可能性創建一個結構 - 這是否是一種好的做法?
  3. 不知何故使用泛型。據我所知,雖然泛型是類型安全的,但不是類型嚴格的,但在使用之前必須將其轉換爲類型。例如,如果我想在這裏列出項目,我需要將它們轉換爲字符串,就像在解決方案1中發生的情況一樣,這使得它無用。

我的問題是,那麼這些選項中哪一個最好?還是有一種替代選擇使用某種我不知道的泛型類型?每種情況下的可能變量的數量可能會改變,就像它們的類型一樣。我希望能夠將單個List或Array返回給調用方法,以便它可以適當地處理結果。它將知道如何處理基於a的值的每組數據,因爲它將是'動作選擇'標識符。我也知道每次將它們投射到物體上並返回是非常緊張的,所以我寧願避免這種情況。

這可能是很簡單,但它已經難倒了我...

+0

爲了提供更多信息,基本上這是根據用戶的選擇嘗試解釋來自輸入字符串的各種數據。如果他們說了一件事情,我需要檢查這些數據,然後抓住它,製作一份這些數據及其類型的列表(各種信息都來源於此信息)。 問題是我想讓它可擴展,所以我總是可以添加東西而不必遵循嚴格的結構,並且我不應該在使用時重新設置所有東西。 我喜歡ArrayList的建議,以及重構。我會嘗試修改它。 – George 2009-09-07 13:49:46

回答

4

既然你不事先知道這個列表將包含這樣做,它看起來像一個良好的情況下使用的ArrayList

如果要使用密鑰返回值,請考慮使用Hashtable

3

.NET中的一般原則是每個類型都可以轉換爲System.Object(雖然它可能涉及裝箱)。您可以使用如下方法:

void Foo(params object[] parameters) { ... } 

或者使用System.Collections.ArrayList類。

「問題」是,當你想使用這樣一個值,你需要這樣的代碼:

if (parameters[i] is string) 
    { 
     string s = (string) parameters[i]; 
     ... 
    } 
2

對不起,這不是一個代碼相關的答案:有可能是設計缺陷隱藏在這樣的結構之後。確保你知道你在做什麼,否則事情可能會回火。

如果不知道你用事先真正需要的字段的類型,這需要與他們的類型保存數據的方法,像

struct foo { 
    private object _value; 
    private string _type; 
    foo(string myType, object myValue) { 
     _value = myValue; 
     _type = myType; 
    } 
} 

,然後使用泛型來處理業務邏輯。

1

您可以使用Dictionary/Hashtable來表示數據項,然後將這些字典添加到List

如果需要,還可以在字典值中添加額外的類型信息。

2

基本上你需要一個輸入到Object的列表,然後是的,你處於一個回退模式。

我的問題是,在結構上,你怎麼知道哪些索引是哪種類型的?這聽起來像是一個痛苦的解決方案。

如果您確實需要在列表中存儲不同類型,請嘗試一個包含每種類型成員的結構,以及一個指示表示哪種數據類型的標誌。然後使用該結構的通用集合。像(把我的頭頂部)

struct FooType 
{ 
    public string StringValue; 
    public bool BoolValue; 
    public int IntValue; 
    public char CharValue; 

    public string DataType; 

    // You'd probably want constructors too 
} 

然後泛型列表的內容:

var values = new List<FooType>(); 

現在,您可以添加和刪除使用該類型,列表中的條目,然後這些指示的核心是什麼數據真的是。

我還是不喜歡這個答案;這聽起來像你的設計可能試圖做太多,並可能有重構機會,但由於我沒有看到更多的代碼或意圖,我所能做的就是回答你所問的問題。 :)