Parse および TryParse Try-Parse および Tester-Doer モードを通じて

DateTime の

Parse と TryParse

Parse(string s) と TryParse(string s, out datetime) は両方とも、文字の日付と時刻を同等の System.DateTime に変換するために使用されます。それでは、関数のパラメータの違いを除いて、それらの間に違いはありますか。まずコードを見てみましょう:

            string dateTimeStr = "";
            DateTime dt = DateTime.Parse(dateTimeStr);

空の文字列を実行して日付と時刻の型に変換します。明らかに変換できず、Parse() は例外をスローします: System.FormatException: s には含まれません。日付と時刻の文字列表現に有効な文字 。ただし、TryParseこの変換メソッドを実行すると、

            string dateTimeStr = "";       
            DateTime dt2; //dt2未经初始化，就被传递给函数TryParse()
            bool sucflag = DateTime.TryParse(dateTimeStr, out dt2);

変換は最初に例外をスローせず、dt2には日付と時刻の最小値が割り当てられ、sucflagはfalseです。関数のコメントを見てください:

このメソッドが返されるとき、変換が成功した場合は s に含まれる日付と時刻に相当する System.DateTime 値が含まれ、変換が失敗した場合は System.DateTime.MinValue が含まれます。 s パラメータが null であるか、空の文字列 ("") であるか、日付と時刻の有効な文字列表現が含まれていない場合、変換は失敗します。 ※このパラメータは初期化せずに渡されます。この関数は例外をスローしません。

Try-Parse

それぞれの違いを確認すると、parse() によってスローされる例外は必然的にパフォーマンスに影響を及ぼします。これは、例外のパフォーマンスを最適化するための設計パターンです。 パターン解析を試す。以下は Microsoft の公式説明です:

パフォーマンスに非常に敏感な API の場合は、前のセクションで説明した Tester-Doer パターンよりもさらに高速なパターンを使用する必要があります。 このパターンでは、メンバー名を調整する必要があります。定義されたテスト ケースはメンバー セマンティクスの一部です。 たとえば、DateTime は、文字列の解析が失敗した場合に例外をスローする Parse メソッドを定義します。また、解析を試みるが、解析が失敗した場合は false を返す、対応する TryParse メソッドも定義します。 out パラメーターを使用して、成功した解析の結果を返します。

Tester-Doer

Try-Parse モードを説明する際、Microsoft は別のモードを提案しました: Tester-Doer モード、Tester-Doer モードとは何ですか? 関数に例外を記述するとパフォーマンスが低下します。Microsoft は、例外の副作用を軽減するためにこのモードを提供しました。

次のコード:

ICollection<int> numbers = 省略获取数据的逻辑
numbers.Add(1);//Add此处不做可写性检查

上記の欠陥: コレクションが読み取り専用の場合、Add メソッドは例外をスローします。このメソッドが呼び出される場所では例外がスローされることが多く、システムのパフォーマンスに影響します。この設計上の欠陥を回避するために、Microsoft は次のように提案しました: 例外をスローするメンバーのパフォーマンスは、メンバーを 2 つに分割することで改善できる場合があります

Add() を次のように分解します:

ICollection<int> numbers = 省略获取数据的逻辑if(!numbers.IsReadOnly) //Tester{
    numbers.Add(1); //Doer}

IsReadOnly

がテスターと呼ばれます。潜在的にスロー操作 を実行するために使用されるメンバー、この例では Add メソッドが doer と呼ばれます。 分解後、読み取りを行います。 -only 検出を最初に行うと、Add によってスローされる読み取り専用例外の数が減り、パフォーマンスが向上します。

まとめ