Develop Reference

Reflection C#: Create instance of an object which has no default constructor

I know that FormatterServices.GetUninitializedObject can do that, but the core library for xbox does not contain the class.
I'm working on a XNA game and I'm trying to make this work there. Activator.CreateInstance is available but than I need a default constructor, what's ugly.
I thought of if there is no default constructor, I take the shortest and pass in any values (for example when it requires an int and an object, I pass in 0 and null).
But the problem on that is that the constructor could throw an exception if it works with the objects passed in. Well I still could write it in a try catch block and maybe it works that way. But I really unlikely would do that. Is there any other solution?
Thanks for any help :)

You don't need the default constructor, I think there's an overload where you can pass parameters in
Activator.CreateInstance (typeof (Foo), new object []{ args});
That said, you can also use reflection to get the constructor and just call that.
Edit: wait - rereading the question, are you saying you don't know what to pass in? Then why are you creating it?

No, this is completely the wrong solution.
You definitely need a default constructor, otherwise you have no business constructing the objects this way.
Note that you can use a "non-default" (I'm taking "default" here as meaning "parameterless") constructor, but you should still pass in the required parameters, not just by type, but by meaning as well.
Since you're resorting to Activator.CreateInstance, I'm assuming you don't know a lot about the type in question, except its Type object. In this (general) case, you should not just pass in some odd values to the constructor in the hopes that it will make sense to the type in question.
If, on the other hand, you have some sort of contract going, where you can say "I know this type supports contract X", you might look into using an interface, and calling a method on that interface after constructing the object. The interface would then have a known method (known to the code that needs to construct the instance) that you would call with known (known as in knowing how many, their types, as well as their meaning) parameters.
Just randomly (passing in 0 and null just to satisfy the signature is just as arbitrary as passing on 42 and some odd object) passing parameters to the constructor is not safe at all.
Example with interface:
object instance = Activator.CreateInstance(someTypeObject);
((ISomeInterface)instance).Initialize(your, specific, parameters, here);
What you might need is a IoC framework, so that you can say "whenever someone needs an instance of this class, here's how to construct it".
Look up:
Inversion of control (IOC) - Wikipedia
Autofac
Ninject
Unity
Castle Windsor
there are more, search for inversion of control C#

You state that your target class does not have a default (or "parameter-less") constructor. Put another way; your class's constructor contains "Dependencies." It cannot (and should not!) be constructed until those dependencies are met.
What you need is a Dependency Injection (or Inversion of Control) container. I recommend looking at Ninject, for excellent implementation which happens to be compatible with XNA.
Dependency Injection frameworks allow you to specify general 'rules,' such that the DI container can "fill in the blanks" when you encounter an object which requires parameters in the constructor. For example, an example of a DI rule for creating type Foo:
"When you try to create an object of type Foo which has a constructor with parameters (int, object), pass these values to the constructor: (0, null)."
Spend a little bit of time glancing through some of the examples on the link provided, for an idea of how to achieve what you're asking using the Ninject library.

About constructors

I got a question about Constructors.I think constructors are all just our convenience instead of setter methods,right? So for an object , the properties you think important(such as required fields in a webform)are passed as parameters into constructor.
Is there any criteria that these many number of parameters should be passed into constructor?
Please elaborate on these points and as well as any points about constructors.
Edit:Sorry about the way i asked question.Yes,we create an object with constructor and we assign values with setters but my question is about the comparison between default constructor with setters and constructor with explicit parametrs.

No, it's not just a convenience instead of setters. In particular, a constructor will only be called once. Using constructor parameters, you can create immutable types which are given their values at construction time - that wouldn't be possible with setters.
It's generally not a great idea to have huge numbers of parameters, whether to a constructor or a normal method. If you find you have a lot of parameters, you may want to create a type representing all the related ones - that type may have a bunch of getters/setters. See ProcessStartInfo for an example of this.

I see it this way:
You pass the parameters in a constructor that are required in order to create an object that is in a 'valid' state.
For your example: I would not pass 'required fields in a webform' to the instance of the class that is filled up with those values.

You have to call setters on an object, and the constructor creates that object. Without a constructor invocation, you'll have no object to call upon.
Re. the number of parameters. If you have a sizable number of parameters, that suggests:
related parameters might be composable into objects themselves. e.g. a start date and an end date into a TimePeriod object
that object has too many responsibilities, and should be decomposed further
Check out the Factory pattern and Builder pattern for some alternatives re. creating objects.
A further note re. constructor parameters and setters. In Java and C#, the parameters passed into the constructior can be used to initialise fields once only, and the fields are immutable from that point on (unlike when you set these via setters). This has great benefits for code reliability (at some cost of object immutability).

Constructors are used to initialise a class. You should pass as many parameters as are required to define your class into the required initial state.
Note that you can also overload a constructor.

If you have some non-optional, and many optional parameters, and you want to avoid looong parameter lists in constructors (which can be very error-prone, especially if the parameters are of the same type), you should favor the use of the
Builder pattern
instead.

You can also consider the use of the Factory pattern for object creation.

I think you should pay more attention to where the objects are being deployed when deciding how to create them. I try to summarize some points that help when choosing which method to use for filling object fields, i.e. constructor or setter methods:
State: By state, I mean the value of all fields of an object in a snapshot of runtime. When developing an application, keeping track of object state is important especially if an object is going to be accessed in multiple threads. Even in single-thread programming, objects may be modified in different methods and classes especially in languages such as Java that passes all objects by reference. Setting the state once and for all the lifetime of an object (in the constructor) and avoiding setters (called immutable pattern) makes programming, especially concurrent programming, really easier. But pay attention that this approach increases object modification cost because all the fields should be copied into a new instance on each modification; for example in Java, compare String (which is immutable) to StringBuilder and StringBuffer (which are stateful). String is thread-safe and easy-to-use but costly for long string creation, while StringBuilder is not thread-safe but fast in concatenating small strings. Meanwhile, StringBuffer is both stateful and thread-safe but costly in every method call because its methods that are synchronized (It means: do not make a stateful object thread-safe when it is not necessary in most of the use cases). So, as a general hint: use constructors (and immutable pattern) for objects which are accessed in multiple threads and use setters for local objects and fields which are under more control.
Injection: When we are using a dependency injection framework such as Spring or Guice, the framework makes one method more preferable than the other. For example, spring encourages setter injection more than constructor injection. Spring constructs the objects (beans) mostly using default constructors and then injects the dependencies using setter methods. Then Spring calls the init (PostConstruct) method for you. So, you can do whatever initialization you want in this method with the dependencies in-place. In contrast, Guice encourages constructor injection as its best practice.
Beauty of Code: Not only having a long list of parameters in a constructor is not beautiful, but also if many other constructors should be overloaded to support multiple optional parameters, these constructors may clash because of having same parameter types. Therefore, using setters is more effective if many of the fields are optional. But I think even in this case, the object usage scenario is more important. Long list of parameters can be resolved by grouping them in other classes, as other developers have suggested here.
To new or To Delegate: Whenever you are going to new an object whether using constructor or setter methods to fill the fields, it is a good practice to think if it may be needed someday that someone else pass (inject, create) it here. This leads to the Factory design pattern which is helpful especially when developing tools and libraries.

What's the fundamental reason for C# to forbid calling the default constructor?

This is a subsequent question to another question I asked here:
Calling constructor from other constructor in same class at the end
The previous one was about how, now the question is why Microsoft designed it this way ?
UPDATE: My question is rather:
Why can't I call a constructor directly AT THE END of another constructor whereas I can call AT THE BEGINNING.
If they forbid call at the end why didn't they forbid to call directly at the beginning also ?

Why can't I call a constructor
directly AT THE END of another
constructor whereas I can call AT THE
BEGINNING.
Well, let's break it down into two cases. (1) you're calling a "this" constructor, and (2) you're calling a "base" constructor.
Suppose you're in the first case. The typical usage pattern for this scenario is to have a bunch of ctors that take different arguments and then all "feed" into one master ctor (often private) that does all the real work. Typically the public ctors have no bodies of their own, so there's no difference between calling the other ctor "before" or "after" the empty block.
Suppose you're in the first case and you are doing work in each ctor, and you want to call other ctors at times other than the start of the current ctor.
In that scenario you can easily accomplish this by extracting the work done by the different ctors into methods, and then calling the methods in the ctors in whatever order you like. That is superior to inventing a syntax that allows you to call other ctors at arbitrary locations. There are a number of design principles that support this decision. Two are:
1) Having two ways to do the same thing creates confusion; it adds mental cost. We often have two ways of doing the same thing in C#, but in those situations we want the situation to "pay for itself" by having the two different ways of doing the thing each be compelling, interesting and powerful features that have clear pros and cons. (For example, "query comprehensions" vs "fluent queries" are two very different-looking ways of building a query.) Having a way to call a ctor the way you'd call any other method seems like having two ways of doing something -- calling an initialization method -- but without a compelling or interesting "payoff".
2) We'd have to add new language syntax to do it. New syntax comes at a very high cost; it's got to be designed, implemented, tested, documented -- those are our costs. But it comes at a higher cost to YOU because you have to learn what the syntax means, otherwise you cannot read or maintain other people's code. That's another cost; again, we only take the huge expense of adding syntax if we feel that there is a clear, compelling, large benefit for our customers. I don't see a huge benefit here.
In short, achieving your desired construction control flow is easy to do without adding the feature, and there's no compelling benefit to adding the feature. No new interesting representational power is added to the language.
For the "base" scenario, it's quite straightforward. You never want to call a base constructor AFTER a derived constructor. That's an inversion of the normal dependency rules. Derived code should be able to depend on the base constructor having set up the "base" state of the object; the base ctor should never depend on the derived constructor having set up the derived state.

Eric Lippert has a blog post about the order in which initializers and constructors run when an object is created. In it he says: "The more derived constructors may rely upon state initialized by the less derived constructors, so the constructors should run in order from base to derived".

I think the technical reason for the behaviour you describe is hinted within the C# specification here:
http://en.csharp-online.net/ECMA-334:_17.10.3_Constructor_execution
Any variable initializers are called as part of the constructor code, and if you were able to call a constructor directly - which is a Very Special Function from the compiler's point of view - you might fire off additional behaviour. With the constructor chaining approach (using the ": this" on the constructor definition) the compiler respects your attempt to call another constructor safely.
I don't think there's really much requirement to call another constructor within the same class (inheritance aside) -- there's nothing you can't do without defining another function and, to be honest, I prefer to do that. If my constructors get lengthy, I usually feel more comfortable pushing it into separate function as I often need to call a complicated "Reset" or "Init" function outside of the constructor.

IIRC from the design of C++, constructors must be called in top-down order because a base class instance is not guaranteed to be useable until its constructor has finished executing. You cannot construct your derived object safely unless you know in advance that your base object is fully initialised and ready to go. If that seems like a trivial point, consider the case where the base class contains private state that is only initialised properly in its constructor. AFAIK the reasoning is the same in the CLR.
The same reasoning applies in the opposite direction. It is only safe to destroy/finalize the base class instance after the derived class instance has been done, because the derived object may rely on the base object's state still being valid.

I'm guessing, but possibly as simple as: it is very rare you want it, and when you do there are usually better options (private/protected initialization methods) that do the job adequately. And without the risk of forgetting to initialize it, or calling a method that relies on data that isn't yet initialized (a reason why calling virtual methods in the ctor is a bit risky).
The only caveat is that you can't use a readonly field with a post-ctor initialization method, but that is IMO less evil than making things more complex for a corner-case.

The purpose of a constructor is to initialize the object.
Overloading the constructors is used when you want to pass some initial parameters to the object.
So the purpose of the design is to have one Mega constructor which accepts all the variables and do all the initializing, and have the other constructors propagate variables, and set default values to parameters not passed from the user.
The idea is to have a single method doing the initialization, and not having seperate constructors each doing something else.

The default constructor is only ever created by the compiler when you don't specify your own constructor. It is a bit of syntactic sugar, to make it easy to quickly create a class.
By writing your own constructor, you are in effect declaring that yes, you are interested in how your objects are initialized. The default constructor is not generated.
Since disabling the default constructor is only possible by writing another constructor, allowing users to call the default constructor would make it impossible to disable it.

Possible to use a singleton with a non-default constructor in C#?

I'm implementing a notification framework for one of my projects. As i want it to be very generic, the user can use several transport layers, so that he doesn't really need to care about using one delivery method (lets say WCF) or another (for eg ActiveMQ).
The interface the user has access is of course independent of the delivery method (WCF or ActiveMQ).
Still, the two classes (consumer and producer) implements singletons, so they actually use default constructors (meaning, no parameters).
My problem is that i would like to have one parameter, the delivery method the user want to use.
But as far as i know, singleton only use default constructors? which is normal, as there should be no point of using singletons with parameters.
So, what are my options here? not to create a singleton? create a method to set the delivery method?
Thank you very much for your help,
Sebastian

You can certainly have parameters with singletons, except instead of passing the parameter into a constructor, you are passing it into the getInstance() method. Your overridden constructor needs to be private of course for a true singleton implementation. My example is written in Java but applies for C# as well.
Example:
Singleton s = Singleton.getInstance(42);
In the Singleton code:
private Singleton() {
}
private Singleton(int num) {
//set num
}
public getInstance(int num) {
//singleton code (calls the private non-default constructor if an object
//does not already exist)
}

There are some dependency injection frameworks like Spring.Net which might help you. You can effectively pass a parameter in a configuration file for your singletons constructor.
Link to a Spring Framework example
Might I suggest that if you have two different behaviours required of your singleton that you might want to subclass. That way you get the behaviour that you want by calling the singleton of the class behaviour you want.

You can do this easily with a dependency injection framework. I have a similar construct in my current project using MEF. All that's required is to use the constructor injection options, and add that assembly and the requested dependency's assembly to the catalog, and it wires it up correctly.
Another option is to have some form of initialize function that takes your option, and constructs the singleton instance. Instead of constructing it on first access, you can construct it during the initialization call. The downside here is that you need to make sure to initialize your singleton before you use it (typically at program start, using a config file).
A similar, but less error-prone option, is to just have the singleton lazy initialize, and give it a "default" option. Allow the caller to set a static property to alter which option is constructed, so if it's set prior to the singleton's construction, you'll get a different default. This can be confusing, though, since again, you need to make sure you set the property before accessing the singleton, or you'll get unexpected behavior.

I know it is late to answer the original question, but i just had this problem and here is how i solved it. Might not be ideal, but it seems to work.
I created a Init method that must be called before trying to use the singleton instance.
public void Init(/*parameters*/)
{
if (_isInitialized)
{
throw new InvalidOperationException("Component is already initialized!");
}
//do your work here
}
Any other access to the singleton instance (properties get, set, method calls) will throw an invalid operation exception telling that the object was not initialized.
I think this does what i need, is less confusing than GetInstance(params) because there is no risk of misunderstanding what the method does. The downside is it will not throw compilation time errors, but the first run without the initialization done will throw an exception, so it should be good enough.

What is the best way to ensure that all necessary class properties are set before returning an object which will be used somewhere else

I have a class that requires a specific method to be called before being used by other objects, this method implements all the required logic and sets the properties of the class to their respective values. How can I ensure that the method of this class is called before the object is returned for use by other objects? I heard that it is a bad idea to implement logic in the constructor so I cannot call this method in the constructor. A code example for this sort of implementation is as follows:
SomeClass myClass = new SomeClass("someName");
//Class must call this method if object is to be of any use
myClass.ConvertNameToFunnyCharacters();
return myClass;

If it's essential that the object is constructed correctly then it's not a bad idea to put the logic in the constructor. You should consider putting the logic in another method - which should be public if you want to be able to "reset" the object back to its default state.

If that method needs to be called before the class can be used then it sounds to me much like what a constructor should be doing. And a constructor is also just a special method, so what should be wrong about "implementing logic in the constructor"?

Make your constructor internal, protected or private according to your needs and implement a Factory pattern.
This is how to proceed when you need some object initialization to avoid high object dependencies.
http://msdn.microsoft.com/en-us/library/ms954600.aspx

Putting a lot of logic in the constructor can lead to a few problems:
If the constructor calls methods of the object, those methods run in a partially constructed object. This can really bite you when you override the method in subclasses: in Java and C# the subclass' implementation will run before the subclass' constructor has initialised the extended state of the object and so fail with null pointer exceptions. C++ works more "correctly" but can cause different confusing effects.
It makes unit testing with mock objects a bit more complicated if the constructor calls back out to objects passes as parameters.
So, I prefer to keep constructors as simple as possible: just assign parameters to instance variables. If I need to perform more complex logic to initialise an object I write a static factory function that calculates the constructor parameter values and passes them to a simple constructor.

The reason it isn't recommended to have a lot of logic in the c'tor is that while in the c'tor the object still isn't valid. If that's what your "other" method does, then it's fine as part of the c'tor.

According to me I will call it in the constructor or you'll make a burden on the class user to call this method before using it