2

私のクラスのコンストラクターには、次の3つの変数が渡されます。

public MyClass(int Id, String Name, DateTime StartDate)

ただし、またはオブジェクトとしてStartDate変数に渡される場合があります。StringDateTime

DateTime1つはforStartDateを指定し、もう1つはとして指定する2つの異なるコンストラクターを作成する必要がありStringますか？または、タイプを作成し、Dynamic実行時にそれが何であるかを判別して、それを処理する必要がありますか？私のクラスには5つの日付があり、さまざまな組み合わせごとにコンストラクターを作成する場合、コードが多すぎるため、質問します。

4

3 に答える 3

6

「文字列」で入力するのではなく、発信者をより強く入力する必要があります。

5つの日付を取るコンストラクターを1つ作成し、呼び出し元に正しいことを強制します。これは、すべてが正しいことをしなければならない25のコンストラクターよりもはるかに正気のようです。

于 2012-07-25T16:54:38.240 に答える
1

デフォルトのコンストラクターを呼び出すコンストラクターのオーバーロードを定義します。

class MyClass
{
    public MyClass(int id, string name, DateTime startDate)
    {
    }

    public MyClass(int id, string name, string startDate)
        : this(id, name, DateTime.Parse(startDate))
    {
    }
}

すべてをDateTimeオブジェクトとして受け入れるコンストラクターと、すべてを文字列として受け入れるオーバーロードのみを作成します。他の組み合わせは無視します。実際、私はDateTimeのみを受け入れます。

動的タイプを受け入れると、インターフェイスが貧弱になります。

于 2012-07-25T16:50:40.800 に答える
1

DateTimeオブジェクトへの文字列変換にはリスクが伴う可能性があります。すべての文字列を正確に変換できるわけではありません。たとえば、次の日付について考えてみます。

  • 2012年2月3日-この日付は3月2日である英国スタイルですか、それとも2月3日である米国スタイルの日付ですか？
  • 1月3日-何年？
  • 1/30/15-これは1915年または2015年の1月30日を指しますか？

アプリケーション全体で文字列を合法的にDateTimesに確実に変換できるかどうかを確認する前に、どのような種類の変換リスクがあるかを知る必要があります。 DateTime.TryParse素晴らしい機能ですが、すべての潜在的な問題を解決できるわけではありません。

コンストラクターでは、強く型付けされたデータ（DateTimeオブジェクトなど）を要求することをお勧めします。

public MyClass(int id, string name, DateTime StartDate)

次に、文字列の解析を、それらの文字列が取得される場所の近くに移動します。たとえば、文字列がソースデータファイルから読み込まれる場合、ファイルの読み込みコードでそれらの文字列を解析し、エラー時に例外をスローできます。別の例として、文字列がユーザーによって入力された場合、ユーザーが日付を直接入力ミスしたときに例外をスローできます。

于 2012-07-25T16:54:14.647 に答える