pure virtual function with unspecified parameters?

M

Markus Dehmann

I have an abstract base class called Data. It has a pure virtual
function

virtual void write(std::eek:stream& out) =0;

which writes the internal data to a stream. Now the problem is that
this is not appropriate for some implementations of the class. Some
implementations have an internal representation that they should
rather write into several separate files. So for those, something like
this would be more appropriate:

void write(const std::string& outputDirectoryName);

What would be a good design for the abstract base class in this case?
It seems like it should require some kind of write function, but with
flexible parameter lists for different implementations.

Certainly we don't want to deal with void pointers:

write(void* toWhatever) = 0;

that the implementation classes would cast and use however they like
because void pointers are evil.

A template also doesn't work:

template<class T>
virtual void write(T& out) = 0;

because you can't template a virtual function. And it would seem like
overkill to template the whole class on this output parameter; after
all it's just a little write function within a much larger class.

What would be a good design in this case?

Thanks!
Markus
 
V

Victor Bazarov

Markus said:
I have an abstract base class called Data. It has a pure virtual
function

virtual void write(std::eek:stream& out) =0;

which writes the internal data to a stream. Now the problem is that
this is not appropriate for some implementations of the class. Some
implementations have an internal representation that they should
rather write into several separate files. So for those, something like
this would be more appropriate:

void write(const std::string& outputDirectoryName);

What would be a good design for the abstract base class in this case?

struct OutputDestBase { virtual ~OutputDestBase() {} };

void write(OutputDestBase const& where) = 0;

Now, make every class have its own corresponding member class that will
derive from 'OutputDestBase' and have the contents known to the owning
class alone, which will permit static_cast (or dynamic_cast if you prefer
to have error-checking) to that derived member class before extracting
any necessary information from it.
It seems like it should require some kind of write function, but with
flexible parameter lists for different implementations.

Certainly we don't want to deal with void pointers:

write(void* toWhatever) = 0;

that the implementation classes would cast and use however they like
because void pointers are evil.

A template also doesn't work:

template<class T>
virtual void write(T& out) = 0;

because you can't template a virtual function. And it would seem like
overkill to template the whole class on this output parameter; after
all it's just a little write function within a much larger class.

What would be a good design in this case?

You're close. Keep digging in the same direction.

V
 
A

Alf P. Steinbach

* Markus Dehmann:
I have an abstract base class called Data. It has a pure virtual
function

virtual void write(std::eek:stream& out) =0;

which writes the internal data to a stream. Now the problem is that
this is not appropriate for some implementations of the class. Some
implementations have an internal representation that they should
rather write into several separate files. So for those, something like
this would be more appropriate:

void write(const std::string& outputDirectoryName);

What would be a good design for the abstract base class in this case?
It seems like it should require some kind of write function, but with
flexible parameter lists for different implementations.

Certainly we don't want to deal with void pointers:

write(void* toWhatever) = 0;

that the implementation classes would cast and use however they like
because void pointers are evil.

A template also doesn't work:

template<class T>
virtual void write(T& out) = 0;

because you can't template a virtual function. And it would seem like
overkill to template the whole class on this output parameter; after
all it's just a little write function within a much larger class.

What would be a good design in this case?

The point of std::eek:stream as an abstract streaming interface is to
separate the data generation from the particulars of where that data
ends up (if anywhere) -- file, http-connection, zip, memory buffer...

So you have the right idea in the abstract Data class.

Just provide more specific additional interfaces lower in the hierarchy,
and implement the streaming-to-std::eek:stream as e.g. XML representation.

If this is impossible, then you have a design error, derived classes
that /are not/ substitutible for the abstract base class, and then you
need to redesign (it does sound as if you have committed the grave sin
of introducing an UBC, a Universal Base Class, the ultimate horror, oten
reflected in meaningless names such as "Data" or "Manager" or "Object").

Above all, think about the knowledge and responsibility distribution of
the system: divide knowledge and responsibility in a clean manner.


Cheers, & hth.,

- Alf
 
A

Alf P. Steinbach

* Victor Bazarov:
struct OutputDestBase { virtual ~OutputDestBase() {} };

void write(OutputDestBase const& where) = 0;

Now, make every class have its own corresponding member class that will
derive from 'OutputDestBase' and have the contents known to the owning
class alone, which will permit static_cast (or dynamic_cast if you prefer
to have error-checking) to that derived member class before extracting
any necessary information from it.

Ouch.

Necessity of casting, except for interfacing to low level C style code,
is generally symptomatic of bad design.


[snip]
You're close. Keep digging in the same direction.

Separation of concerns is a good design guideline, but the current
direction is opposite.

Cheers, & hth.,

- Alf
 
M

Markus Dehmann

I have an abstract base class called Data. It has a pure virtual
function

virtual void write(std::eek:stream& out) =0;

which writes the internal data to a stream. Now the problem is that
this is not appropriate for some implementations of the class. Some
implementations have an internal representation that they should
rather write into several separate files. So for those, something like
this would be more appropriate:

void write(const std::string& outputDirectoryName);

What would be a good design for the abstract base class in this case?
It seems like it should require some kind of write function, but with
flexible parameter lists for different implementations.

Certainly we don't want to deal with void pointers:

write(void* toWhatever) = 0;

that the implementation classes would cast and use however they like
because void pointers are evil.

A template also doesn't work:

template<class T>
virtual void write(T& out) = 0;

because you can't template a virtual function. And it would seem like
overkill to template the whole class on this output parameter; after
all it's just a little write function within a much larger class.

What would be a good design in this case?

Thanks for all your answers and the lateness of this reply.

After reading up on Design Patterns, it seems to me that the Visitor
pattern would fit perfectly here and solve my problem. You all were
concerned about separation of responsibilities. So, just adding a

void accept(const Visitor& v){
v.visit(this);
}

should be fine and keep the class small. Then, different
implementations can define their own WriteVisitor version, like this:

class WriteVisitor : public Visitor {
void visit(const MyData& d){
// write by calling the appropriate functions specific to MyData
}
};

Markus

P.S.: Before getting the Visitor idea, I "solved" the problem by just
adding a

void write(const std::string& name);

function. Some implementations can write to a stream (e.g. to cout if
name=="-"), others can write to a directory of that name, etc.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,989
Messages
2,570,207
Members
46,783
Latest member
RickeyDort

Latest Threads

Top