Hi,
I have a possibly stupid question about library design. Suppose you have a
module A with function fa_1(...), ..., fa_n(...) and two modules B1 and B2
with different implementations of some functions fb_1(...), ..., fb_m(...),
i.e. B1 and B2 share the same interface but have different implementations .
Module A should use either module B1 or module B2 to accomplish its task.
In C++ (or Java or whatever) I would propably create an abstract base class
B
class B {
public:
virtual void fb_1(...) = 0;
...
virtual void fb_m(...) = 0;
};
and derive two subclasses B1 and B2 from with different implementations .
Module A would be given a pointer two an instance of B
class A {
public:
void set_B(B* b);
...
};
and so on.
A direct translation to C could be a struct B holding function pointers,
i.e.
struct B {
void (*fb_1)(...);
...
void (*fb_m)(...);
};
and then create a struct with the function pointers pointing to the
functions of B1 or B2. The module functions of A would the call B1 or B2
with a construct like
struct B* b;
....
b->fb_1(b, ...);
So far so good, nothing new. With the above approach I there're many lines
in A like
a->b->fb_1(a->b, ...)
to call functions from B1 or B2. Furthermore, A and B both have contain a
large number of functions (so not only one function pointer). This seems
to be pretty ugly.
My question is: Are there better ways to organize a library where a module A
can use either functions from B1 or B2? All modules implementing the
interface B are known at compile-time, i.e. it should not be possible to
link against the library and create new implementations of B. But of
course, the library itself should be extensible in the sense that I want to
provide 3 or 4 implementations of B as part of the library in future. Is
there a way not to mimic the approach of C++ (with abstract base class and
so on) using structs with function pointers? How could the library and the
modules be organized to get the desired functionality? Or is the approach
described above *the* standard way to do this?
Thanks in advance!
Frank
I have a possibly stupid question about library design. Suppose you have a
module A with function fa_1(...), ..., fa_n(...) and two modules B1 and B2
with different implementations of some functions fb_1(...), ..., fb_m(...),
i.e. B1 and B2 share the same interface but have different implementations .
Module A should use either module B1 or module B2 to accomplish its task.
In C++ (or Java or whatever) I would propably create an abstract base class
B
class B {
public:
virtual void fb_1(...) = 0;
...
virtual void fb_m(...) = 0;
};
and derive two subclasses B1 and B2 from with different implementations .
Module A would be given a pointer two an instance of B
class A {
public:
void set_B(B* b);
...
};
and so on.
A direct translation to C could be a struct B holding function pointers,
i.e.
struct B {
void (*fb_1)(...);
...
void (*fb_m)(...);
};
and then create a struct with the function pointers pointing to the
functions of B1 or B2. The module functions of A would the call B1 or B2
with a construct like
struct B* b;
....
b->fb_1(b, ...);
So far so good, nothing new. With the above approach I there're many lines
in A like
a->b->fb_1(a->b, ...)
to call functions from B1 or B2. Furthermore, A and B both have contain a
large number of functions (so not only one function pointer). This seems
to be pretty ugly.
My question is: Are there better ways to organize a library where a module A
can use either functions from B1 or B2? All modules implementing the
interface B are known at compile-time, i.e. it should not be possible to
link against the library and create new implementations of B. But of
course, the library itself should be extensible in the sense that I want to
provide 3 or 4 implementations of B as part of the library in future. Is
there a way not to mimic the approach of C++ (with abstract base class and
so on) using structs with function pointers? How could the library and the
modules be organized to get the desired functionality? Or is the approach
described above *the* standard way to do this?
Thanks in advance!
Frank
Comment