Design issue: pointer to member function VS switch VS other solutions

  • Thread starter Alf P. Steinbach
  • Start date
A

Alf P. Steinbach

* Luigi Malagò:
people *p = new people();
people.setAddMan();
parser->parse("man.txt",people);
people.setAddWoman();
parser->parse("woman.txt",people);

People people;
parser->parse( "man.txt", people.men() );
parser->parse( "women.txt", people.women() );
 
?

=?ISO-8859-15?Q?Luigi_Malag=F2?=

Hello,
i'm new to function pointers. I have some code that parses some
configuration files using flex and bison. I have to use the same parse
for different files, but the information i parse have to be add to
different collections. I have a C++ class that wraps the code that
invoce the parser. I pass to the parser an object that works as a
container for the different object i have to parse.

Let make an example. I have to parse men.txt and woman.txt. I have a
class People (a container for men and women, where i want to keep them
in different lists), with different methods: addMan(person p) and
addWoman(person p). The parser creates person p and then invokes a
method add(person p) that will call addWoman or addMan according to what
the user decide.

people *p = new people();
people.setAddMan();
parser->parse("man.txt",people);
people.setAddWoman();
parser->parse("woman.txt",people);

In this way the invocation of the method parse is the same for every
type of file i parse (men or women), and so i do not have to maintain
more versions of flex and bison files...(note taht a good idea would be
to create e hierarchy of parsers, but since i use flex and bison, this
is not possible, i would have to duplicate all the code for the parsers..)

I can change the behavior of add(person p) simply using a switch and a
bool variable, or otherwise using pointer to member functions. The first
question is: which is the best solution? In this case are pointer to
functions worth using?

Besides that, i'm not sure i'm following the best approach...

Do you have any suggestion to improve my design? I though about having
man and woman class, but this would mean to have different files for
bison ( i would have to create two parsers), since the parser has to
create different objects according to the file parsed. (otherwise i
could use a boolean variable into the parser, but i dont like this idea
since it would make my parse dependent on the type on the objects of the
collection...)

Another option would be pass to the parser dinamically at runtime the
type of object to create (man or woman), and then invoke always the same
method addPeople(person p), and than ckeck dinamically what kind of
object has been passed.

I hve many ideas in my mind, but i'd like hear from you what do you
think is a nice design.

thanks a lot,
Luigi Malagò
 
?

=?ISO-8859-1?Q?Luigi_Malag=F2?=

Alf P. Steinbach ha scritto:
* Luigi Malagò:

People people;
parser->parse( "man.txt", people.men() );
parser->parse( "women.txt", people.women() );

Are you passing to the parser the collection where to add the objects,
instaed of the whole container (of both men and women)?
Could you explain it a little bit further your solution?

thanks a lot,
Luigi
 
?

=?ISO-8859-1?Q?Luigi_Malag=F2?=

Luigi Malagò ha scritto:
Alf P. Steinbach ha scritto:

Are you passing to the parser the collection where to add the objects,
instaed of the whole container (of both men and women)?
Could you explain it a little bit further your solution?

thanks a lot,
Luigi

I forget to mention that to me (in my application) men and women are the
same, i mena, i never thought to create sublasses of person since the do
not differ at all. The only difference is to with collection inside
people the are added.

Another important think is that in case a pass as function pointers the
members i want the parser to use to add the object t people, i would
have to pass both "addPerson" (pointing to addMan or addWoman) but also
another method (at least one, i think) since before adding the object to
the collection i have to add to is some information that i can get from
the object people. For doing that i have to call getPets(string name)
and then add what i get to the person p. In my application the list of
pets depends on whether person is a man or a woman. So i thought about
having another pointer getPets that refers to getPetsForMan(string name)
ot getPetsForWoman(string name).

The whole is getting a little bit complicated and now i doubt about my
choice..

NOTE: I know this example is a little bit sutpid, the real application
is more complex and i'd like to focus on the problem rather then the
real example..

Luigi
 
G

Grizlyk

Luigi said:
Are you passing to the parser the collection where to add the objects,
instaed of the whole container (of both men and women)?
Could you explain it a little bit further your solution?

I forget to mention that to me (in my application) men and women are the
same, i mena, i never thought to create sublasses of person since the do
not differ at all. The only difference is to with collection inside
people the are added.

One of the flexible ways, if you want to divide people
in future more, to do like this:

declare parser's storage class interface
{
};

At this point no sence to make "people" as derived from "storage",
because "people" contains more than one "storage"

You will be forced to pass people to parser if only parser will access
to all man/woman/children together, but simultaneously will have any
preffered selected type of storage (man for example).

declare people class interface
{
storage& man();
storage& woman();
storage& other();
};

declare parser class interface
{
parser::parse(file&,storage&);
};

Usage

do_parse(Tpeople *people, Tparser *parser)
{
parser->parse("man.txt",people->Man() );
parser->parse("woman.txt",people->Woman() );
parser->parse("children.txt",people->other() );
parser->parse("old.txt",people->other() );
}

Tpeople *people = new Tpeople;

do_parse(people, new Tlex_parser);
do_parse(people, new Tbison_parser);

Not enough information to apply desing patterns, but all looks like
simplest kind of design pattern "builder" with "storage" as "concrete
builder without derived" and "parser" as "concrete derived from
director".
 

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,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top