Re: Call virtual function in constructor
* Pavel:
It is sometimes useful to initialize different classes of a hierarchy
with the derived class-dependent code and then return back to the base
class constructor to execute some of its code again to avoid duplicating
that latter common code.
For example (this code will not work in C++ but the analogous code will
work in other programming languages (e.g. Java) and I do not see any
fundamental design flaws in this code).:
typedef std::map<std::string> ConnectionParameters;
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
}
};
"not ... any fundamental design flaws": heh, it is reportedly the most
common source of Java bugs.
The problem is that at the time the derived class' function
implementation is called, the derived class object has not yet been
initialized. Thus, member functions called from that function, or even
that function's own implementation, may very easily execute code that
relies on assumptions that have not yet been established. Apart from
run-time checking of array downcasts, which is also a strong contender,
I think that this is the most ugly type system breach in Java.
This way, you can perform all validation in the constructor, that is,
according to the best practices, and without duplicating the common
validation code in the derived class.
The above code is (unfortunately) common practice in Java, but it's
certainly not best practice.
It's an example of the exact opposite.
It is an anti-pattern.
It is a C++ - specific feature that the implementation is not required
to construct the memory layout for the whole object of the most derived
class before calling the first constructor of a base class (Java does it
differently).
Of course, there are ways in C++ to cure this limitation, for example by
composition, where you can create a parallel Impl hierarchy which does
not validate, use member access control and "friends" to make its object
accessible only from within the primary hierarchy classes, move
database-specific init() into the parallel hierarchy and leave the
validateConnection() in the main hierarchy's base class. Sometimes this
added design complexity will be not much of a burden, sometimes it will
be. Personally I would prefer to have a choice not to use it.
For ways to achieve dynamic binding during initialization (DBDI) in C++,
which also are more sane ways in Java, see FAQ item 23.6.
I think of that as "my" FAQ item since I convinced Marshall to include
it, but the text and exposition is of course Marshall's.
Unfortunately this happened much later than the treatment of clone
functions, so we're stuck with the term "virtual construction", at least
in the FAQ, referring to cloning, and the acronym "DBDI" (Marshall's
invention) for the techniques discussed in 23.6.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?