Re: std::map of differente std::vectors
Andre Casteliano wrote:
Okay, so I'd simply assume that you have a common interface for
serialisation, which means a baseclass typically. Further, you have a
kind of registry, where "all objects" are stored, so you can iterate over
all of them in order to store them.
Yes.
class Customer : public BusinessBase {};
class Product : public BusinessBase {};
...
We?re using the DAO pattern to read/write objects to a relationa database
(SQL server, for instance).
So, the interface for DAO access is in fact in BusinessBase, with
implementations there or in a derived class, right?
You might be able to use a template function to serialise different kinds
of objects. Then, you neither have to derive from a common baseclass (you
only need a common interface) nor do you have to store all of them in the
same container, only make one function call per object type.
Sorry, but I don?t get the idea ... are you talking about template
specialization ?
// Note: similar interface but without a common baseclass!
class customer {
void write( ostream& out) const;
};
class product {
void write( ostream& out) const;
};
template<typename T>
void
write_to_stream( ostream& out, vector<T> const& t)
{
for( size_t i=0; i!=t.size(); ++i)
t[i].write(out);
}
The above function template can be invoked with vectors of any type that
supplies a suitable write function. BTW: this is also called compile-time
polymorphism in contrast to runtime polymorphism.
O RLY? Aren't they sometimes vector<Supplier> or vector<Product> for
GetSupplierVector() and GetProductVector()?
Exactly. And it?s our main problem today. Lots of code that differ only
on input parameter type and return values.
Okay, that means that you can't return a vector<BusinessBase>, because it
would slice off the derived part of the objects. What you can do is return
a vector<BusinessBase*> which you create on demand from the various
vector<>s you already have.
Alternatively, you could take a look at the visitor pattern and
simply 'visit' all the various objects, performing necessary
serialisations.
Uli