CODEWITHSUNDEEP
c#
AspOnMyNet
AspOnMyNet

Reputation: 1998

Wouldn’t Type.CreateInstance made more sense than Activator.CreateInstance?

1) If we want to create an instance of a given type during runtime ( thus using late binding ), then we need to call Activator.CreateInstance. But wouldn’t it be more efficient if Type class had such a method? If nothing else, Type.CreateInstance could return strongly typed instance instead of System.Object?!

2) Type.GetType enables us to pass into it only the friendly name of the assembly containing the type, thus it doesn’t enable us to specify the absolute path to this assembly.

Any idea why Type.GetType allowing us to specify an absolute path to the assembly would be a bad idea?

thanx

Upvotes: 1

Views: 378

Answers (6)

Lars Truijens
Lars Truijens

Reputation: 43645

1) You can, but I'm not sure if these are nicer then using Activator.CreateInstance

object obj = someType.GetConstructor(Type.EmptyTypes).Invoke(null);
object obj = someType.InvokeMember("", BindingFlags.CreateInstance, null, null, null);

2) Not using a full Assembly Qualified Name to load a possible unexpected type and can have strange results as explained here.

Specifying the location to load the assembly from is something only Assembly.LoadFrom does. Assembly.LoadFrom is deprecated in the newer .Net version. The reason for that is when you use LoadFrom you do need to be aware that the assembly is loaded in a different context and unexpected things could happen. So it is a good thing Type.GetType does not has such a feature.

Upvotes: 1

Will Marcouiller
Will Marcouiller

Reputation: 24152

Using Reflection, you may also search for the right ConstructorInfo and invoke it for your type, then you will get a strongly-typed instance and be able to late-bind it.

EDIT ConstructorInfo.Invoke(object[])
It is not stronly-typed and one will be obliged to type-cast before using the new instance of Type T.

Upvotes: 1

Dean Harding
Dean Harding

Reputation: 72678

As for your question as to why Type.GetType doesn't let you specify the full path to the assembly, again we go back to the single responsibility principle. Assembly.Load is how you load assemblies, Type.GetType only works with currently-loaded assemblies.

Upvotes: 2

Hans Passant
Hans Passant

Reputation: 942478

Well, you can, just need to make an extra hop. You can use Type.GetConstructor() and call the returned ConstructorInfo.Invoke() method.

Type.GetType() will also take a assembly-qualified name. Or you could use Assembly.Load() and Assembly.GetType() to get the Type instance.

Upvotes: 1

Reed Copsey
Reed Copsey

Reputation: 564911

Type has a single purpose: it defines a unique "Type" within the runtime environment.

Keeping Activator a separate type, as well as Assembly for the assembly information, is a good thing. Having small classes which define a single purpose and usage is a better design.

Moving Activator.CreateInstance into Type would not make it more efficient - it might make it easier to conceptualize in your specific scenario, but it would cause type to become larger and more complex. I personally find the current design very clean and nice, and am glad that they've kept the Type class unique to defining a type, and left other information (such as Assembly info and construction) in separate types.

Upvotes: 3

moribvndvs
moribvndvs

Reputation: 42495

  1. Activating a type may need to work with COM interop and Remoting, so having Type deal with that is putting too many eggs in one basket (aka poor design). You do have Activator.CreateInstance<T>(), but you need to know the type at compile time.

Upvotes: 1

Related Questions