my English is not the best, but I hope you understand me.
I have a design question and maybe you can give me some tips about it. Well, I'm using the elementary class 'BaseElement' in my code that contains some getter, setter and members for type, length and rawData. The 'type' member identify the content of the rawData. Every type of the baseElement need other functions to parse or modify the content of the rawData. What is the best way to do this?
here is the elementary class (just an example):
class BaseElement
{
public:
// some getter, setter, constructors...
private:
int type;
std::vector<unsigned char> rawData; // content to be read/modify
}
Option 1: The parser does not need any temporary variables or anything like that, so I could use a namespace for the parser functions. However, in this case each function need the 'BaseElement' as first argument.
namespace Parser
{
namespace TypeA
{
void doThisA(BaseElement &obj) {...}
void doThatA(BaseElement &obj) {...}
void doSomethingElse(BaseElement &obj, int whatEver) {...}
...
}
namespace TypeB
{
void doThisB(BaseElement &obj) {...}
void doThatB(BaseElement &obj, double anything, int anythingElse) {...}
}
namespace TypeC
{
...
}
...
}
usage example:
void myFunction(BaseElement &obj)
{
...
if (obj.getType() == 1)
{
Parser::TypeA::doThisA(obj);
Parser::TypeA::doSomethingElse(obj, 123);
}
else if (obj.getType() == 2)
{
Parser::TypeB::doThisB(obj);
Parser::TypeB::doThatB(obj, 10.0, 678);
}
else if (...)
{
...
}
...
}
Option 2: I create classes for every parser and pass the BaseElement object as reference during instantiation:
class ParserTypeA
{
public:
TypA(BaseElement &obj) : bo(obj);
void doThisA() {...}
void doThatA() {...}
void doSomethingElse(int whatEver) {...}
...
private:
BaseElement &bo;
}
class ParserTypeB
{
...
}
usage example:
void myFunction(BaseElement &obj)
{
if (obj.getType() == 1)
{
ParserTypeA t(obj);
t.doThisA();
t.doSomethingElse(123);
}
else if (obj.getType() == 2)
{
ParserTypeB t(obj);
t.doThisB();
t.doThatB(10.0, 678);
}
else if (...)
{
...
}
...
}
...or are both solutions bad? Is there possibly a design pattern for it? ...or a better solution?
best regards, SBond
Aucun commentaire:
Enregistrer un commentaire