Re: Is it bad to have objects pass themselves to new objects?
k04jg02@gmail.com wrote:
My app has a bunch of different data types, and a bunch of different
graph types that can draw the data. This is a pretty much a 1:1
mapping -- one graph type for each data type.
Hmmm, why is the graph type a class at all, wouldn't it be enough to make it
a set of functions for each data type? In that case, a simple virtual
function would do the job.
However, this would entangle the drawing code with the data handling code,
which gets really messy if you have several targets for drawing on. In that
case, I'd suggest using the so-called visitor pattern (aka double dispatch)
which conveniently allows extending a class with "external virtual
functions".
One way I've heard of handling this situation is to have a factory.
The factory would take in the data and put out the appropriate graphs.
I thought, "That seems unnecessary, why not just have the data types
know what graph type they correspond to..." So something like this:
class Graph {};
class GraphA {
public:
GraphA(dataA* data) : _data(data) {}
void Render() { /* Do some stuff with data to make a
pretty graph */ }
private:
dataA* _data;
};
I have one problem with this code, and that is ownership. Who owns '*_data'?
Who is responsible for releasing it? If possible at all, I would manifest
the ownership semantics of this in the code itself, i.e. use a reference if
ownership remains external, use an auto_ptr if ownership is transferred and
use a shared_ptr if ownership is shared.
class data {
public:
virtual Graph* BuildGraph() = 0;
};
class dataA : public data {
public:
virtual Graph* BuildGraph() { return new GraphA(this); }
};
How is this code called? Typically, I would expect it like this:
data* d = ...;
Graph* g = d->BuildGraph();
g->Render();
delete g;
Now, this is actually a case where I wonder why this Graph object gets
created in the first place and why this code doesn't immediately call the
Render() function. If the Graph object only does the rendering and uses the
connected data object for that, this is really nothing more than a
complicated way to write a virtual function. If the Graph object creates
some kind of cache with writing operations from the data object in the
constructor and renders it in the Render() function, it doesn't need the
data object afterwards.
Now instead of plugging the data into a factory to make a graph you
just do data->BuildGraph() and it makes the graph. My question is: is
this a bad idea? Is there some reason why a factory is preferable?
I would say that this actually is a kind of factory, i.e. a data object is a
factory for a graph object.
One problem I noticed is that if later GraphA and dataA are made
templates, then their declaration and source both goes in their
headers, and you end up with circular #include's because dataA needs
to know about GraphA in order to instantiate it, and GraphA needs to
know about dataA in order to plot it.
Not quite, you can still separate templates in declarations and definitions
as usually, only that you then need to instantiate the required template
instantiations explicitly somewhere. This might seems clumsy, but actually
you don't need new instantiations that often in practice.
Uli
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]