2

.Netでは動的呼び出し（リフレクション、C＃動的キーワードなど）が可能ですが、C＃などの言語を使用する場合、プログラムが正しいことを証明するために静的型付けを使用する必要があると感じることがあります。実行時の入力の問題。

これにより、コンパイラに次のように説明するためだけの料金のインターフェイスまたは基本クラスが導入される場合があります。'はい、このコンテキストに渡すすべてのオブジェクトが理解されることを知っています。 、インターフェース定義を使用してそれを証明します！」（たとえば、.netは内部でIReadChunkBytesインターフェイスを使用して、SteamReadChunkBytesまたはBufferReadChunkBytesオブジェクトを何らかのメソッドに渡すことができます。）

また、クラスや型を作成して、type-yとはあまり役に立たない他の目的を果たすこともあります。たとえば、動作が小さい一意の識別子（列挙型に少し似ています）や、定数のセットを保持するなどです。

このような設計上の決定に直面したときに、コンパイル時間、実行時間、およびその他のコストがどのようになるかをよりよく理解することに興味があります。「この問題を解決するためだけに、新しいタイプまたはインターフェイスを定義する必要がありますか？」明らかに、そのような比較のそれぞれのコストと利益には2つの側面がありますが、一般に、そのような比較/議論のそれぞれで「新しいタイプの定義」に同じコストが見られることを願っています。これらのコストをどのように定量化しますか？

4

3 に答える 3

4

新しいインターフェイスまたはクラスを静的に作成するためのパフォーマンスおよび/またはスペースのコストは、常に無視できます。この意味であまり考えないでください。対照的に、リフレクションと遅延バインディングは深刻なパフォーマンスの問題を引き起こす可能性があります。ほぼすべての機会に静的型付けを使用する必要があります。

新しいクラスまたはインターフェイスの作成に関連するコストは、パフォーマンス コストではありません。それらはより多くの人的コストです。以下は、新しいクラスまたはインターフェースを追加する前に考慮すべき事項のリストです。いずれにせよ、レイト バインディングやリフレクションを使用しても、プログラムの役に立たない可能性があります。これらは最後の手段です。

  • プログラムの複雑さ。多くの場合、これは当てはまりませんが、一般的な経験則では、すべてのクラスがアプリケーションに追加の複雑さを追加するため、実行時の理解、新しいプロジェクト メンバーへの引き継ぎ、記憶、図解が難しくなります。変更の実装はより困難になります。
  • クラスが必要だと本当に思わない場合は、おそらくそうではありません。より動的なクラスを使用するなど、問題を解決する他の方法があるかもしれません。おそらく、継承やその他の手法を使用して繰り返しを減らすことができます。
于 2012-09-19T22:28:38.260 に答える
1

ほとんどすべてのものには、いくらかのランタイム コストがあります。唯一の例外は、空きスペースなどです。その理由は、ローカル変数名、パラメーター名、定数など、ほぼすべてが IL イメージに記録されるためです。したがって、少なくともディスク コスト、仮想メモリ スペース コスト、作業スペース コストが発生します。

CPU に関しては、メタデータが増えると、プログラムの起動、トークンの解決、JIT/NGEN が遅くなります。

ただし、タイプを追加すると、パフォーマンスにプラスの影響を与えることもあります。

于 2012-09-19T23:10:23.480 に答える
0

強力な型よりも動的な型を使用すると、パフォーマンスの問題が発生する可能性が高くなります。したがって、dynamicほとんどのオブジェクトで問題なく使用できる場合は、静的型を作成するコストについて心配する必要はないかもしれません。

補足: 動的型付けを好む場合、C# は最適な言語ではない可能性があります。また、ほとんどの C# コードは厳密に型指定されたオブジェクトを対象としているため、適切なサンプルを取得するのは困難です。

于 2012-09-19T22:36:34.093 に答える