Re: Call virtual function in constructor
....
class FooConnection {
protected:
virtual void init(const ConnectionParameters &pars) = 0;
public:
FooConnection(const ConnectionParameters &pars) {
init(pars);
validateConnection();
}
private:
void validateConnection()
throw(FooConnectionException /*defined elsewhere*/)
{
/* perform some uniform validation here, for example
some select from "FOO_MAIN_TABLE" */
}
};
class OracleFooConnection : public FooConnection {
protected:
void init(const ConnectionParameters &pars) {
// .. do Oracle-specific initialization
}
};
class MySqlFooConnection : public FooConnection {
protected:
void init(const ConnectionParameters & pars) {
// .. do MySql-specific initialization
}
};
....
I think you meant to write "It can hardly be argued that initialization
is only supposed to operate on initialized objects".
No, I meant what I said -- that initialization is what makes an object
initialized, so it, by design, is supposed operate on the objects that
are not yet initialized (ok, maybe not necessarily "only").
In C++ this is dealt with by constructors, which, as opposed to other
member functions, operate on not-yet-initialized objects.
This is not true. The Standard allows calling "other member functions"
from the constructor and these functions operate on not-yet-initialized
objects with pre-determined results -- even virtual functions -- unless
the virtual call "uses an explicit class member access". So, the
Standard is OK with the member functions operating on
not-yet-initialized object.
What is not allowed is "referring to a nonstatic member before the
constructor begins execution" and that's what I would like to see
relaxed to allow at least an access to non-static member *functions*,
because, contrary to its name, constructor does not "construct" an
object in memory, but initializes it. Member functions do not require
initialization in constructor; in fact, nothing of a member function can
be changed in the constructor; therefore, unless it reads, directly or
indirectly, some uninitialized *data* members, its call would do no harm.
The problem with Java's virtual calls from constructors can be restated
in these terms, that that mechanism does not deal with that problem.
Specifically, that it causes member functions other than constructors to
operate on not-yet-initialized objects (or more precisely, for Java, on
objects that have not yet had their class invariants established).
Just replace the word "causes" to "allows" and I will agree with the
facts in your statement. As for your conclusion ("the problem"),
however, it may or may not be the problem in each particular case of
using it but it is definitely not the problem of the language. It is a
feature, sometimes useful (not very often but not extremely rarely,
either) and dangerous when misused at the same time.
What's wrong is the earlier "This way...", the virtual call (in Java and
some other languages) in the constructor invoking a function
implementation in a derived class.
See above
That is not necessary in order to keep all validation in the
constructor, nor is it necessary in order to ensure that client code
only has access to valid objects.
It is one way of making sure the client code always accesses
the valid object -- which is the "best practice" I referred to. I have
never stated it was the only way, so I do not think we have a
disagreement here.
....
It is an anti-pattern.
I did not call the code above a pattern but "anti-pattern" seems
little "out of wack" to me :-). Why don't we try to refrain from
tagging or rubber-stamping each other's examples?
The above was a precise (well, OK, not that precise!) technical
description.
Coming from rural Northern Norway, you know, fishermen and such, I can
assure you that when I resort to name calling, you'll know it... :-).
See <url: http://en.wikipedia.org/wiki/Anti-pattern> for a general
introduction to antipatterns.
Well, I agree they give a reasonable definition. It is more or less in
line with direct GoFs definition of a pattern. According to Wikipedia,
to be an anti-pattern:
1. A pattern of actions must be "repeated" -- compare to GoF's involving
a solution for a "general design problem" in their problem definition.
2. It must "ultimately produce" the "bad consequences outweighing the
hoped-for advantages"
3. A refactored solution must be "clearly documented, proven in actual
practice and repeatable"
My problem does not fit a single bit of the above definition. It is:
1. Specific, just a case to address the Kira's question to the original
poster "why you would want to invoke a method that your object wishes to
override"
2. Does not produce (in Java) or would not produce (in the hypothetical
C++ example) any bad consequences.
3. The suggested alternatives (including my own for C++) are worse than
the original course of actions. They add unnecessary complexity and do
not address an issue in the original solution (because, IMHO, there is
no issue).
Doing a Google search for a name of this particular antipattern didn't
turn up any hits.
However, since it is an antipattern it's called an antipattern here &
there on the net, e.g. <url:
http://mehranikoo.net/CS/archive/2006/11/28/InstanceConstructors.aspx>
and <url: http://debasishg.blogspot.com/2006_11_01_archive.html> (which
indicates the Eclipse can detect this antipattern automatically).
The first referenced article states that the "Template Method" pattern
becomes an anti-pattern if used in Constructors. I was far from stating
the opposite, my context is much more narrow -- how to re-factor the
constructor code to address the particular valid business requirement.
Once again, we are discussing a particular problem and whether or not
the tool (C++) is helpful enough to solve it.
Your second reference is from really afar field. It demonstrates how
Java aspects fire a thread that would access an incompletely constructed
object. Not sure how it is relevant -- the class constructor does not
have to call any virtual methods of its class to create such a problem.
Again, this demonstrates the misuse of a language feature -- explicit
thread support in Java. If C++ supported threads, same misuse would be
possible in C++. I hope nobody suggests to ban the Thread support due to
the possibility of this misuse (I admit this case is much more extreme
than in our case).
....
Perhaps you may find my original sketch for that item more clear, <url:
http://home.no.net/alfps/cpp/faq_proposal/@virtual-functions.html#faq-20.7>
I read it, thank you. Your part-creator solution is probably the best to
to solve my sample case and is similar to my own alternative solution
(in both design and, unfortunately, the complexity)
It would go like (off the cuff)
class ConnectionFactory
....
Handle create( Params& const params ) const
Add one more class for Handle
....
....
class FooConnection
....
class OracleFooConnection : public FooConnection
....
class Factory: public ConnectionFactory
....
> It splits things up very nicely in terms of responsibility, the
> communication lines are very clear (as opposed to communication via
> member variables, which is almost the same as global variables), and
> there is no call of non-constructor function on uninitialized object.
You solution illustrates the point I am trying to make really well --
thank you, no irony here. We ended up with 5 non-trivial communicating
classes (ConnectionFactory, Handle, FooConnection, OracleFooConnection,
Factory), because our requirement was:
"I want to factor out some code that is common for all classes in my
class hierarchy and is supposed to be called *after* the class-specific
code when I initialize my objects"
If only our requirement had the word *before* in place of *after* above,
we would undoubtedly have to write only 2 classes (FooConnection and
OracleFooConnection) and the communication would be really trivial,
nothing to talk about.
Isn't it obvious that our tool of choice (C++) stands in our way in this
particular case? Of course we can appease ourselves that we accomplished
more than just solving the original problem (implemented the Factory and
Handle "mini-frameworks" in your solution and implemented Factory
mini-framework and reduced the dependence of the client code on the
implementation in my solution -- I threw in some Bridge) but..
- who asked us to do all that?
- who is going to pay for all that (in money or project time) if we
don't need to re-use all that and it was not asked for?
- who is going to test all that if it was not required by the business
and pay for that, too?
- who is going to document all those clear communication lines and then
talk every newcomer to the team into following our "right ways"? They
may be right but they surely will not be most intuitive for him/her. And
then, s/he has to write a separate Factory for every new FooConnection
and not forget to create that Handle, not a connection itself..
Long story short, is this ban of our little language feature (which we
would know how to use safely) worth the trouble?
..>
Cheers, & hth.,
- Alf
Regards
-Pavel