どうやら、彼らは「混乱している」ようです。それが本当の理由ですか?他に思いつきますか?
10 に答える
多くの開発者が ref/out を本当に理解していないのを見たことがありますか?
本当に必要な場合に使用しますが、それ以外の場合は使用しません。これらは通常、2 つ以上の値を効果的に返したい場合にのみ役立ちます。その場合、少なくともメソッドが 1 つのことだけを行うようにする方法があるかどうかを検討する価値があります。場合によっては、ref/out を使用することが最も適切なアプローチです (さまざまな TryParse メソッドなど)。
私の意見では、それらはコードのにおいと見なされます。一般に、オブジェクトを返すというより良いオプションがあるからです。
お気づきのように、.NET ライブラリでは、いくつかの特殊なケース、つまりtryparse のようなシナリオでのみ使用されます。
- クラスを返すことは、値の型をボックス化することを意味します
- メソッドの契約では高速である必要があるため、ボックス化/ボックス化解除は実行可能なオプションではありません。
混乱することがおそらく最良の理由です。混乱とは、保守性が低下し、微妙なバグが発生する可能性が高くなることを意味します。「goto」制御フローステートメントと同様のビューでそれらを確認します。それ自体は本質的に悪いことではありませんが、何十年にもわたってプログラムを読んだり理解したりすることが不可能な多くの人々につながっています。
コードを混乱させる可能性のあるものには近づかないでください。
そうは言っても、これらのキーワードは、おそらくフレームワーク開発者がそのようなものの必要性を認識したために存在します。適切な回避策がない場合はそれらを使用しますが、可能な場合は避けてください。
ref/out は自動的に可変性を意味し、不変値を使用した関数型プログラミングは最近大流行しています。Dictionary.TryGetValue への呼び出しを LINQ クエリに挿入してみてください。API は変数を宣言する必要があり、API の「流暢さ」を台無しにします。
これが「理由」というわけではありませんが、「理由」の一例です。
(こちらもご覧ください
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!181.entry
関数型言語がそのような API をどのように処理するかについての解説が必要です。)
ref / outも「Func」デリゲートでは機能しないため、これらのスタイルAPIは、デリゲートを使用する他のAPIとの構成/再利用性が低くなります。
考えただけですが、返されたデータをキャプチャするのではなく、引数がターゲットメソッドの実行状態をキャプチャする場合、ref/out が役立つことがわかりました。Customer オブジェクトを返すサービスからエラー メッセージを取得するシナリオを考えてみましょう。
Customer GetCustomerById(int id, out string errorMessage);
このメソッドが失敗した場合、null Customer オブジェクトを返すか、例外をスローする可能性があります。ただし、エラーの原因 (バリデーション? データベース?) を知りたい場合は、out 引数を使用します。ここでの errorMessage 引数はデータとは関係なく、単にメソッド実行の問題点をキャプチャするために使用されます。
個人的には、2 つ以上の重要なデータ/値を返すことが期待されるメソッドがある場合、コードの設計を再考します。
@TraumaPony この .NET フレームワークのガイドラインのソース (URL など) を教えていただければ幸いです。
私が言われた理由は、ref/out が使用されたときに 1.0 GC に問題があったためです。2.0 の GC (おそらく 1.1 もそうではない) にはこれらの問題がないため、通常、GC は現在では役に立たないレガシーであると想定します。
オブジェクトを返す必要があるのは、おそらく ref または out を使用しないことを提案する最も可能性の高い理由です。
「ref」は実際にはスカラー値を渡すときにのみ使用する必要がありますが、とにかく参照によって渡されるオブジェクトによく使用されます。
コードの複雑さだけでは十分ではありませんか? 比較:
int myValue;
ReadFromSomewhere(ref myValue);
に:
int myValue = ReadFromSomewhere();