それができることは知っていFormatterServices.GetUninitializedObjectますが、xbox のコア ライブラリにはクラスが含まれていません。
私は XNA ゲームに取り組んでおり、そこでこれを機能させようとしています。Activator.CreateInstance利用可能ですが、デフォルトのコンストラクターが必要です。何が醜いのですか。
デフォルトのコンストラクターがない場合は、最短のものを取り、任意の値を渡します (たとえば、 と が必要な場合はintとをobject渡します)。しかし、それに関する問題は、渡されたオブジェクトで動作する場合、コンストラクターが例外をスローする可能性があることです。それでも、try catch ブロックに記述でき、おそらくそのように動作します。しかし、私はそうする可能性はほとんどありません。他の解決策はありますか？0null
助けてくれてありがとう:)
いいえ、これは完全に間違った解決策です。
間違いなくデフォルトのコンストラクターが必要です。そうしないと、この方法でオブジェクトを構築するビジネスがありません。
「デフォルトではない」(ここでは「パラメータなし」を意味する「デフォルト」を使用しています) コンストラクタを使用できますが、必要なパラメータは、型だけでなく意味によっても渡す必要があります。
に頼っているので、オブジェクトActivator.CreateInstanceを除いて、問題の型についてあまり知らないと思いTypeます。この（一般的な）ケースでは、問題の型に意味があることを期待して、奇数の値をコンストラクターに渡すだけではいけません。
一方、「このタイプがコントラクト X をサポートしていることはわかっています」と言うことができる何らかのコントラクトがある場合は、インターフェイスを使用して、オブジェクトを構築した後にそのインターフェイスでメソッドを呼び出すことを検討できます。インターフェイスには既知のメソッド (インスタンスを構築する必要があるコードに知られている) があり、既知の (その数、型、および意味を知ることで知られている) パラメータを使用して呼び出すことができます。
ランダムに (0 を渡しnullて署名を満たすためだけに 42 といくつかの奇妙なオブジェクトを渡すのと同じくらい恣意的です) パラメーターをコンストラクターに渡すことは、まったく安全ではありません。
インターフェイスの例:
object instance = Activator.CreateInstance(someTypeObject);
((ISomeInterface)instance).Initialize(your, specific, parameters, here);
「誰かがこのクラスのインスタンスを必要とするときはいつでも、ここでそれを構築する方法があります」と言うことができるように、必要になるのは IoC フレームワークです。
調べる：
デフォルトのコンストラクターは必要ありません。パラメーターを渡すことができるオーバーロードがあると思います
Activator.CreateInstance (typeof (Foo), new object []{ args});
つまり、リフレクションを使用してコンストラクターを取得し、それを呼び出すこともできます。
編集：待ってください-質問を読み直して、何を渡せばよいかわからないと言っていますか？では、なぜそれを作成しているのですか？
ターゲット クラスにはデフォルト (または「パラメーターなし」) のコンストラクターがないと述べています。別の言い方をすれば; クラスのコンストラクターに「依存関係」が含まれています。これらの依存関係が満たされるまで、構築することはできません (そしてすべきではありません!)。
必要なのは、依存性注入(または制御の反転) コンテナーです。XNA と互換性のある優れた実装については、 Ninjectを参照することをお勧めします。
依存性注入フレームワークを使用すると、コンストラクターでパラメーターを必要とするオブジェクトに遭遇したときに、DI コンテナーが「空白を埋める」ことができるように、一般的な「ルール」を指定できます。たとえば、タイプ Foo を作成するための DI ルールの例: 「パラメーター (int, object) を持つコンストラクターを持つタイプ Foo のオブジェクトを作成しようとする場合、これらの値をコンストラクターに渡します: (0, null)。 "
Ninject ライブラリを使用して求めていることを達成する方法のアイデアについては、提供されているリンクの例のいくつかを少し見てみてください。