Re: Duplicating behaviour: Similar algorithms and similar data
Marcus Kwok <ricecake@gehennom.invalid> wrote:
Rune Allnor <allnor@tele.ntnu.no> wrote:
I have a program where the user specifies a number of input
parameters.
The program is implemented such that the user input is colleced as a
list of "core parameter" objects inside a "basic job specification"
object.
The specification object can then be fed to one of several "computer"
objects (sorry, can't find a better word...) where the computations
are implemented.
In general, this works fine.
However, one of the computer objects requires the input parameters to
be parsed and certain status information to be appended to each
of the parameter objects.
The naive way becomes:
class CoreParameter {
// User input
};
class JobSpec{
CoreParameter *p;
};
class ExtendedParameter: public CoreParameter{
// Internal status parameters added
};
class ExtendedJobSpec{
ExtendedParameter *p;
};
and all of a sudden one needs to duplicate the behavior
between classes JobSpec and ExtendedJobSpec. The
parameter classes are *similar* between the two cases,
but not equal. The job specification classes are *similar*
but not equal. Both for the xParameter and xJobSpec
classes, the functionality of the base classes is
preserved. The only changes are the added internal
status parameters and the associated private or
protected handler logic.
What are the options for managing these sorts of
situations?
Since ExtendedParameter is derived from CoreParameter, and you are
working with pointers, then I see no need for the ExtendedJobSpec
because the CoreParameter* p can point to an ExtendedParameter. Then,
in your code that consumes the JobSpec's (I assume you have access to
JobSpec::p in order to access the parameters) you could use a
dynamic_cast:
class CoreParameter {
// stuff
protected:
virtual ~CoreParameter() { }
};
class JobSpec {
friend void compute(const JobSpec&);
CoreParameter* p;
};
class ExtendedParameter : public CoreParameter {
// more stuff
};
void compute(const JobSpec& js)
{
ExtendedParameter* ep = dynamic_cast<ExtendedParameter*>(js.p);
}
personally I'd use a vitual int which() const {return some_int};
providing the most derived type and a switch or if cascaded to
produce the results. working on each extension only not the whole
struct unless needed. so the real only thing they need to derive from
is something like
struct param_base
{
virtual int which()const = 0;
virtual ~param_base(){}
};
struct core_param:param_base
{
int which() const {return 0;}
};
struct extend_one:param_base
{
int which() const {return 1;}
};
struct extended_two:param_base
{
int which() const {return 2;}
};
then a Job can contain a container of param_base *'s [smart ptr
preferred] and provide a method to add param_base *'s from what ever
inputs initial data, and a container iteration to preform the task.
no dynamic casts, as long as the mapping of int to most derived type
is known.
class Job
{
std::vector<param_base *> items;
struct perform_task
{
void operator () (param_base *); // perform task with on this
part.
};
public:
void add(param_base *p) {items.push_back(p);}
void do_it()
{
for_each(items.begin(),items.end(),perform_task());
}
};
now the only thing changing with Job is perform_task::operator () if
additional items are added to the hierachy.
sample implementation of operator () above
void JOb::perform_task::operator () (param_base *p)
{
int which = p->which();
// how to reduce code depends on the job :)
// with which we know the current tyoe,
}
no dynamic casts, and one virtual call per item per pass thru the
container.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]