Constructors and Inheritance – Why is this still so painful?

re: Constructors and Inheritance – Why is this still so painful?

Enrique Ferreyra — Thu, 11 Dec 2008 13:24:37 GMT

I also would like to call other constructors in a arbitrary line of other constructor, not just the first. (C#)

re: Constructors and Inheritance – Why is this still so painful?

int19h — Wed, 26 Nov 2008 11:37:27 GMT

Kyle, anyway, what's wrong with factory interface approach? It seems to be entirely compile-time and type-safe, yet handles any kind of complex initialization well. Yes, it's slightly more verbose, but so what?

re: Constructors and Inheritance – Why is this still so painful?

int19h — Wed, 26 Nov 2008 11:36:28 GMT

> Namely, if you cannot be guaranteed that an object is properly initialized after you call the virtual Initialize method, then what guarantee do you have that they implemented their ctor properly so as to initialize their object correctly?

If an Initialize method fails (exception or not), you still have an object on which you called it, it's just in a (supposedly) unusable state. The client can still try to call something, and the implementer will have to check that someone is trying to work on uninitialized object and throw (or ignore the checks, but that means undefined behavior - and that's not good).

With constructor, if initialization fails, it can throw, and the caller will not get the uninitialized or half-initialized instance. Of course the implementer still has the burden of doing initialization correctly - but he has a way of ensuring that, if initialization goes wrong, the client will not be able to use the object regardless.

re: Constructors and Inheritance – Why is this still so painful?

Kyle Szklenski — Sun, 23 Nov 2008 00:47:54 GMT

Never mind. My solution for it is terrible. I had considered writing a simple test-IOC container that allowed a person to put certain constraint attributes on ctors, so that when you register a type to be resolved on the base type, it would check it and throw an exception immediately if the derived did not have the same ctors defined as the base-class constrained ones. I realized, however, that that has the obvious setback of tying a person down to that IOC container - and it's a bad idea anyway. It's too much of a work-around, rather than a solution, so I didn't bother posting it.

re: Constructors and Inheritance – Why is this still so painful?

Kyle Szklenski — Fri, 21 Nov 2008 14:22:13 GMT

After reflecting on this more, I realized that having a virtual ctor does not solve the problem you brought up in number 2, Tom.

Namely, if you cannot be guaranteed that an object is properly initialized after you call the virtual Initialize method, then what guarantee do you have that they implemented their ctor properly so as to initialize their object correctly? True, if you had a virtual ctor, then you could at least be guaranteed that YOUR ctor would be called at some point (as long as you make sure that the keyword virtual on a ctor doesn't actually mean virtual, because that would require the derived types to call base.Ctor, again), but this does not in any way imply that the object is constructed properly - there could have been many other pieces of data that it needed because it's the concrete type and not your abstract type.

I'm not sure that this is really all that important. Since .NET can handle the situation you're talking about by having a separate initialization method (or what not), including the possibility of some kind of virtual ctor seems like overkill. I like your idea of having T : new(params) a lot, though. I had actually tried that when I was more naive, because I thought, "Why would that NOT work?" But it didn't, of course. In any case, I think I've come up with a temporary solution to the problem. I will be posting it on my blog tonight or tomorrow morning, after I have had a little time to work it all out. It's only temporary because it will only work at run-time, not compile-time, and I'd like to solve this problem for compile-time. If we had template-metaprogramming as C++ does, we could use a compile-time assertion and (I believe) be guaranteed that they have the proper ctors defined for you to use, but we don't, so my solution is only a run-time solution. I'll come back and let you know when I post, if you'd like.

re: Constructors and Inheritance – Why is this still so painful?

Kyle Szklenski — Thu, 20 Nov 2008 15:27:53 GMT

Tom listed,

"2. The class can't be sure it's been initialised properly, since the initialisation call is separate to the constructor."

By the way, I view this as slightly wrong. The use of the call to initialize is for the person writing the framework (or whatever it is). In other words, you CreateInstance on the type, and then immediately call Initialize on it - you don't hope that they do.

Now, if you're saying that it may be the case that the person who implemented your interface and added their Initialize method did not write the Initialize method correctly, then that's their fault, not yours. I wouldn't agonize over that.

re: Constructors and Inheritance – Why is this still so painful?

Tom Hollander — Thu, 20 Nov 2008 12:36:24 GMT

Mendelt - What you're saying is true much of the time. Normally when you construct an object you know exactly what type you are dealing with (even if you plan to use it polymorphically later), so having an arbitarary constructor isn't a problem.

However when dealing with plug-ins, you need to polymorphically _create_ objects, not just use them. So when building a plug-in framework, it would be nice if you could make the constructor part of the contract of the base class. I'm definitely not advocating making this feature mandatory in all classes.

BTW I assume you're just referring to my second proposal. My first proposal wasn't about making constructors part of a contract, it was just about making it easier for an inherited class to reuse all of its base class's constructors if it so chooses.

Tom

re: Constructors and Inheritance – Why is this still so painful?

Mendelt Siebenga — Thu, 20 Nov 2008 12:29:17 GMT

I think you're looking at contracts the wrong way.

There's a great tradition of separating usage of a class and construction of a class (see the discussion on the factory patterns in the GoF book for more on this) Think of interfaces more as a contract for the consumer of a class than the implementer of it. A consumer of a class shouldn't be depending on a way to construct a class so the contract doesn't include that. This is basic separation of concerns. If construction of a class is complex enough to warrant it's own contract it's probably complex enough to warrant it's own abstract factory. You can then create an interface on that factory.

re: Constructors and Inheritance – Why is this still so painful?

Tom Hollander — Thu, 20 Nov 2008 12:05:38 GMT

Rob - The approach you've listed is useed a lot, but I already listed two limitations with it in my post (assuming we don't know at compile time what the concrete type is):

1. We can't be sure it has a default constructor

2. The class can't be sure it's been initialised properly, since the initialisation call is separate to the constructor.

re: Constructors and Inheritance – Why is this still so painful?

Rob — Thu, 20 Nov 2008 11:54:53 GMT

Woops, just thought, there is not even a need to hide the constructor.. Sorry, not had morning coffee yet!