問題タブ [generic-constraints]

リストに新しい項目を追加する関数に一般的なリストを渡そうとしています。私は次のような単純化された例を持っています:

それを呼び出すメソッドに次のエラーがあります。

T' must have a public parameterless constructor in order to use it as parameterジェネリック型またはメソッドの型T'

私がやろうとしていることは可能ですか？コンパイラは、それがどのようなリストであるかを気にするべきではないので、それはそうあるべきだと思います.パブリックのパラメータなしのコンストラクタを呼び出して、渡された既存のリストに新しいインスタンスを追加するだけです.

問題は、インターフェイスが実装者にパブリックコンストラクターがあることを保証していないことだと思いましたが、具体的なクラスを指定しても、次のエラーが発生します。

T' must be convertible toジェネリック型またはメソッドでパラメータ `T' として使用するためのタイプBayClass'

任意のポインタに非常に感謝します。

C＃では、Nullable<T>型は一般的な制約を満たしていませんwhere struct（AFAKは技術的には構造体です）。これを使用して、ジェネリック引数が null 非許容値型でなければならないことを指定できます。

もちろん、参照型の制約Nullable<T>も満たしていません。where class

Nullable 値型ではなく、参照型または値型である必要があるなどの制約を定義することは可能ですか?

このようなもの ：

T通常、型パラメーターをシール型 (型など) から派生するように制約することはできませんstruct。適合できる型は 1 つしかないため、これは無意味であり、ジェネリックは必要ありません。したがって、次のような制約があります。

また：

非常に正当な理由で違法です。

ただし、別の型パラメーターに制約する場合、その他の型パラメーターが実際の型に "置換" された (たまたまシールされた) 場合に、これが発生することがあります。クラスを考えてみましょう：

これは非常に無実です。具体化では：

にTFromType等しくしstringます。これは意味があるかもしれません。他のメンバー以外M<>の ただし、M<>それ自体は引き続き使用できます: コード:

実行して書き込みます：

コンソールに。したがって、制約は本質的に になりましwhere TFromMethod : stringたが、それでも問題ありませんでした。

この質問はTFromType、 が値型の場合に何が起こるかについてです。そこで、今回は次のようにします。

では、なぜcandd宣言からの呼び出しが許可されていないのでしょうか? 結局、 .に制約されるstrangeDateコンパイル時の型があります。だから確かに暗黙的に? 結局のところ、これは（上記）で機能しました。TFromMethodDateTimestrangeDateDateTimestringclass ExampleOne

公式のC#言語仕様の関連する場所を参照した回答を希望します。

を追加しようとするときに...dと入力strangeDate.Adすると、IntelliSense (Visual Studio のオートコンプリート機能) が のすべてのアクセス可能なインスタンス メンバーのリストを表示するDateTimeので、明らかに IntelliSense は呼び出しdが正当であると判断することに注意してください!

もちろん、cとdをコメントアウトした後、 ExampleTwo(witheとf) と次のコードを使用できます。

実行して書き出す：

私は Unity3D (C#) で作業しています。そこでは、このジェネリック クラスが定義されています。

これは、他のクラスが派生するシングルトン型のテンプレートです。

MonoBehaviourクラスにはあまりにも多くのフィールドとメソッドが含まれているため、返された (T 型の) Singleton インスタンスが乱雑にならないように、次の型を定義しました。

これはまったく問題ありませんが、次の新しい型定義ではコンパイラ エラーは発生しません。

一般的な制約は、T が MonoBehaviour と I の両方である必要があることを宣言します。この場合、それは満たされていませんが、コンパイラ エラーはありません。何故ですか ？

同様の問題を見つけることができませんでしたが、見逃した場合はお気軽にリダイレクトしてください。リポジトリ パターンに慣れようとしています。

うまく動作しないようにしようとしているコードの例を示します。これらは、私が使用しているエンティティを表すクラスとインターフェースです。

次に、リポジトリ インターフェイスへ

汎用リポジトリ

次に、データベースからのユーザーのロードを処理する、より具体的なリポジトリ:

DBUser クラスを作成したのは、将来、別のタイプの保存を処理する XMLUser を自由に作成できるようにするためです。AbsObj から継承する User から継承します。IAbsObj を実装しています。それにもかかわらず、DbUser オブジェクトが作成したリストに追加しようとすると、DBUser から T に変換することは不可能であるというコンパイル時エラーが発生しました。助けてくれてありがとう！

別の Generic を定義する必要がある Generic Type Constraint の制限について、かなり一般的なシナリオがあります。

すでに議論されていますが (Eric Lippert 自身と他の人)、これまでのところ、次のシナリオに遭遇したときに適用できる一般的なガイドラインや経験則を見ていません。

これは問題ありません。インターフェースを使用するか、次のように新しい基本クラスを作成することで、いくつかの回避策がまだあります。

これは問題ありませんが、新しい正当な継承レイヤーを追加したい場合はどうなりますか?

またはさらに悪いことに (コードが明らかにコンパイルできない場合)、実際のタイプ セーフがない状態で非常に愚かになります。

その時点で、人々は通常ノーと言います。設計はそれほど複雑ではありません...ビジネス要件を確認し、コンポジションとの大規模なインターフェースを使用するだけです。継承は、追加のコードを書くために節約するためだけではなく、それらのクラスは何らかの形を形成する必要があります家族の中で、彼らは親切な家族を形成しています。

十分に公平ですが、これは私が告白しなければならない状況を実際に解決するものではありません。

はい、それらはあなたを本当に夢中にさせ（再帰的制約など）、髪の毛を引っ張らせる可能性があります...しかし、特にタイプセーフに関しては、これが便利な状況があります。

とにかく、これらの制約に関して、トラックに戻るために従うべき最も適切で一般的なガイドラインは何ですか?インターフェイスを使用するか、コンストラクターでタイプサブセットを選択する以外の解決策はありますか?