Creating object instance without calling its constructor
For a long time I have been in need of a mechanism that allows me to create an instance of an object without calling any of its constructors like the Activator.CreateInstance does. All this time I have also been aware of the fact that it can be done. My motives weren't strong enough to dig dipper in to the problem, though. Until recently...
On my recent project I have enforced the use of a factory pattern for creating each object so for example to create a Document object we use something like Document.CreateDocument(). To enforce the use of this method, all classes should have a no public constructors declared. So it worked that way for some time now. Recently I have been forced to make some changes to the code and I have found the public parameterless construcor on the class that I have been modifying. A quick scope change to private and no compiler errors - good I thought. But..
Then came the runtime exceptions :-(. A quick memory refresher to remind me that the reason the public parameterless constructor is there lies in the parts of the code which use the late binding mechanisms of Reflection such as Activator.CreateInstance which throws errors in the runtime. I have used this mechanism in MyObjectDataSource control to create objects for insertion. Another place was a simple in house data mapper.
Now my motivation has been upgraded to a level that pushed me to make some investigation and after a while I've found the solution: FormatterServices.GetUninitializedObject. This thingy creates your objects without calling any constructor. Sweet! No more problems for me.
I have also checked the performance of this kind of instantiation and it is very good, much faster than Activator.CreateInstance. The only drawback is that any logic from the constructors is not invoked, but that is not a major issue for me since mostly the objects construced in such a way are data transfer objects. I also wonder WHY Microsoft controls such as ObjectDataSource does not use this technique but forces you to have the parameterless construcor?
posted by Mikeon at
3:32 PM
5 Comments:
"I also wonder WHY Microsoft controls such as ObjectDataSource does not use this technique but forces you to have the parameterless construcor?"
Probably because the GetUninitializedObject method does something naughty, which is violate encapsulation and information hiding. When you call that method, sure you get an instance of an object, but that object may not be in a state that it considers to be valid. Per the documentation of GetUninitializedObject:
"Because the new instance of the object is initialized to zero and no constructors are run, the object might not represent a state that is regarded as valid by that object. The current method should only be used for deserialization when the user intends to immediately populate all fields."
You as a user of the object need to *know* that you have access to all of the fields that need to be set for the object to be valid. In good OOP, that's simply not possible.
With all that being said, this is definitely a cool feature, and could be very useful, as it is for you. But in my mind, it's in the same category as using reflection to call private methods on objects. You can do it, but you need to be very careful.
By
John B., at 6:35 PM
Sure it is not initialized and may be in incorrect state but is it really such a big difference when the other option is forcing you to have a parameterless constructor which may not be a valid solution in many situations? Take for example aspect oriented programming with where many of the frameworks require that the object be constructed by factory method. Or maybe there are other dependencies which your object requires to be in a valid state and those should be passed in the constructor. Other reasons exist also, but keep in mind that mostly when you do a databinding with ObjectDataSource, what you really do is using a type of data transfer object since handling any business logic at this point is close to impossible - what you use is just getters and setters.
By
Mikeon, at 10:30 PM
I try to solve this problem by creation of objects factory
You will find my article at
Universal factory of objects
By
Anonymous, at 7:11 PM
Check the control freak factory pattern. It allow class inheritance, blocks direct call to constructors, and enforces the use of the factory.
By
Marraco, at 6:04 PM
Chicago Cutlery Fusion
By
Anonymous, at 11:39 PM
Post a Comment
<< Home