どちらのメリットまたはデメリットは何ですか?
2 に答える
私のガイドラインは常に最も具体的で、最も一般的です。
データ型が一般的であるほど、それを使用するコードはデータ型について認識しなくなります。たとえば、メソッドがコレクションを返す場合、メソッドが生成した新しく作成されたコレクションを返します。内部データ構造を返す場合は、 に上げIEnumerable<T>
ます。
ただし、配列を返す場合、またはList<T>
それが内部的に構築されたものであるため、データを取得するコードはコレクションのより多くの機能にアクセスできるようになりました。
スペクトルのもう一方の端である、最も一般的な (制限内の) データ型を返すことはIEnumerable<T>
、メソッドが内部で新しい配列を構築してそれを返したとしても、すべてのコレクションに対して常に返すか、同様のものを返すことを意味します。呼び出しコードが使用する必要がある場合、呼び出しコードはコレクションの内容を新しい配列またはリストに手動でコピーする必要があります。
これは、より多くの、そしてほとんどの場合、不必要な作業を意味します。
入力については、使用できる最も一般的な型を使用するため、コレクションについては、特に配列やリストなどが必要でない限り、IEnumerable<T>
. そうすることで、コードの呼び出しで行う作業が少なくなります。これは、内部で何らかの作業を行う必要があることを意味する可能性があるため、トレードオフです。
重要な部分は、バランスを取ることです。一般的すぎたり、具体的すぎたりしないでください。いつでも、いつでも。意味のある適切な型を見つけ出し、データを渡したり、コードから発信データを受け取ったりするために、呼び出し元のコードが何をしなければならないかを検討してください。仕事は少ないほどいい。
一般的に、私はより一般的なタイプを選びます。そうすれば、戻り値の型に関する情報を使用する可能性のあるクライアントを壊すことはありません。
より一般的な型を返す場合は、アクション メソッドの実装でいつでも型を別のものに変更できます。次のシナリオを考えてみましょう: から派生したカスタム アクションの結果を返しますActionResult
。コード ベースのどこかで、戻り値がMyCustomActionResult
. その場合、戻り値を変更すると、クライアント コードが壊れてしまいます。
ところで:アクションメソッドだけでなく、すべてのメソッドに対して同じことを行います-最も適切な一般的な型を返します-。
編集:これは私が戻ってくるという意味ではないことに注意してくださいobject
。課題は、「最も適切な」抽象化を表す型を見つけることです。