Re: To dynamically bind, or not?
On Jan 20, 3:14 pm, Dom Bannon <nos...@nospam.com> wrote:
I do a fair amount of C++ but, I have to confess, very little
hard-core OO stuff. I've got a problem with a design decision,
deciding whether to use dynamic binding or not, and I'd appreciate
some input.
The problem is quite straigtforward. I had to knock up a quick
database analysis program a few months ago. This reads a large CSV
file, creates an internal database, and searches the records of the
database.
I then had to repeat this, for a slightly different CSV file, and a
slightly different internal database, with slightly different
searches. So, I've now got several thousand lines of code in 2
slightly different programs, which I need to clean up, to stop them
diverging.
The architecture is very straightforward. I've defined a class which
is the basic record, and I make a std::set of these records (a few
million of them) when I read in the CSV file. This set is the central
data structure, and I pass a reference to this set to my database read
and write functions, and to the search functions. The records are
different in the 2 programs, but about half the fields are common; one
of them is 60 bytes when coded on disk (recordA), and the other is 72
bytes (recordB).
My basic plan is/was:
1 - create a base class which is common to both recordA and recordB;
this contains about half of the old fields
2 - derive recordA and recordB from this base class, filling in the
remaining fields
3 - change the central dataset so that it's now a set<baseClass*>,
instead of set<recordA> or set<recordB>
4 - pass around the new dataset to the file read and write functions,
and the search functions. These are now polymorphic.
However, I'm now wondering if this is worth the effort. First off, I
have to keep all the records on the heap myself, and maintain a set of
pointers to these records, instead of just letting the set hold the
actual record.
Second, all the functions which actually do any work (searching, for
example) now get passed a pointer to a base class. Every time a member
function gets called (millions of times, for millions of records) the
program has to execute the same bit of compiler code to determine if
it's actually calling the code for recordA or recordB. Note that the
answer is always the same for an entire program run - we will always
call the recordA code in run A, and the recordB code in run B.
I'm now starting to think that the record inheritance is worthwhile,
but I might just as well keep the old set code, and just #ifdef the
two separate requirements. The required object type is always known
during a program run, so is dynamic binding actually of any use here?
Thoughts?
The other guy told you: template :-).
struct /*class, whatever*/ recordBase
{
// type, field.
t1 f1;
t2 f2;
t3 f3;
// ...
};
void LoadFromDSVLine(const char* line, recordBase& rec)
{
knockYourselfOutLoading(line, rec);
}
Up here, I presume that you have simple delimiter-separated line of
text with your record fields in it. You might create a corresponding
constructor in recordBase/A/B, but that means adding one more
responsibility to your record class, and SOLID teaches us differently,
so...
program A:
struct recordA : public recordBase
{
// A-specific fields
ta1 fa1;
ta2 fa2;
// ...
bool operator<(const recordA& rhs) const { return
knockYourselfOutComparing(*this, rhs); }
};
void LoadFromDSVLine(const char* line, recordA& rec)
{
LoadFromDSVLine(static_cast<recordBase&>(rec));
}
typedef std::set<recordA, comparisonFunctionA> setA;
Then you do the same for program B.
Goran.
P.S.1 Instead of parsing stuff myself, I would try looking for DSV
parser (there's some out there). I hope you did at least try that ;-)
P.S.2 I am intentionally using term D(elimiter)SV, not CSV, because I
am a bit of an i18n prick, and quite a big part of the world isn't
using a comma for these things.