カスタムデータ型（構造体）vs配列

Question

3つのテキストボックスにテキストを表示するコンボボックスがあります。

コンボボックスの項目は50の州であり、テキストボックスには州の法令に関する情報が表示されます。今、私は多次元配列を使って各状態のデータを保持しています（配列の各項目は状態、項目1、項目2、項目3を保持します）。

私の質問は：3つの項目を保持する州のデータ型を作成する方が良いか、よりコンパクトなのでしょうか。私は配列が好きではありません、それはまさに私が今やっている方法を知っているだけです。

ほとんどの場合、3つのデータ型が繰り返し使用されます。

たとえば、そのうちの1つは州の使用するタイムゾーンであるため、6つのオプションしかありません。

私の目の前にコードがない、または私が投稿したもの、私が考えていたものです。

Answer 1

多次元配列について質問しなければならない質問は、「別のプログラマーがそれを見て、何が起こっているのか理解できますか？

よりコンパクトですか？たぶんmaybyではありません。それはすべてコードに依存します。実際には、メモリ要件が非常に低い場合を除き、おそらく問題はありません。このように考えると、各タイムゾーンが4バイト（整数のサイズ）を占めるとしましょう。タイムゾーンごとにエントリがあるということは、50 x 4 = 200バイトを使用したことを意味します。いずれにせよ心配するほどではありません。

私はそれを変更します.6ヶ月後には、おそらくそれが何をするのかを理解することが難しくなるからです。可読性とメンテナンス性はほとんどすべての状況で重要です。

ので、多分例は次のとおりです。私はあなたがやっている正確に理解するために

class State 
{ 
    public State (string stateId, int timeZoneOffset) 
    { 
     StateId = stateId; 
     TimeZoneOffSet = timeZoneOffset; 
    } 

    public String StateId {get;set;} 
    public int TimeZoneOffest {get;set;} 
} 

public class StatesAndTerritories 
{ 
    List<State> _states = new List<State> 
    public StatesAndTerritories() 
    { 
     //_state.Add state information here 

     _state.Add(new State("AZ", -6); ...... 

    } 

    public IEnumerable<State> GetStates(){ 
    return _state; 
    } 

    public IEnumerable<State> GetStatesInZimeZone(int timezone) 
    {} 

    etc.. 
} 

Answer 2

カスタムタイプは、名前でプロパティにアクセスでき、エラーが発生しにくく（インデックスよりも名前を混乱させるのが難しい）、メンテナンス可能です（プロパティは「ソート」されません）、不要なlengthそれはプロパティの数に合っている必要があり、異なるタイプのプロパティが必要な場合は型の安全性があります）。

Answer 3

ソースコードが参考になります。

純粋なパフォーマンスが目標であれば、各状態の情報を保持する構造体を持つ単一次元配列を提案します。

これにより、要素へのアクセスが高速化され、どの変数にどの値（配列インデックスの代わりに名前付き変数）があるかを把握しやすくなります。構造体は値型であることを覚えておくことが重要です。それを別の関数に渡すと、関数は元の構造体ではなく構造体のコピーを取得します。これは配列で直接作業する場合には問題ありませんが、Listを使用したり、選択した状態情報を別のメソッドに渡す必要がある場合には問題になります。