C++Talk.NET

TheGreatAvatar · Guest

I want to be able to decouple interface code from algorithmic code in
an established code base. I would like to be able to exchange the
interface code without affecting the algorithmic code. In the
established code base there is a very tight coupling of the interface
code with the underlying algorithmic code.

(very crude) Example:

class BInterface;

class AInterface
{
// -=- assume a large amount of boilerplate support code to deal
// -=- with interface/interface communication

public:
// -=- these are the exposed interface methods to be called

virtual void foo(BInterface::BInterface_ptr) = 0;
virtual Interface::BoolType bar(BInterface::BInterface_ptr) = 0;
}

class AImpl : public virtural AInterface
{
public:
// -=- these are the exposed interface methods to be called

virtual void foo(BInterface::BInterface_ptr pB)
{
// -=- do stuff like store pB for later use....
pB->run(this);
};

virtual Interface::BoolType bar(BInterface::BInterface_ptr pB)
{
return container.exists(pB);
}
}

class BInterface
{
// -=- assume a large amount of boilerplate support code to deal
// -=- with interface/interface communication

public:
// -=- these are the exposed interface methods to be called

virtual void run(AInterface::AInterface_ptr) = 0;
}

class BImpl : public virtual BInterface
{
public:
// -=- these are the exposed interface methods to be called

virtual void run(AInterface::AInterface_ptr pA)
{
// -=- do some stuff
bool good = pA->bar(this);
};
}

I know this is a silly example so don't ding me on simple
implementation issues. What I'm trying to do is show how tight the
interface code and the algorithmic code are coupled (algorithmic work
done within the interface code).

I want to be able to abstract the *Impl classes to allow any type of
coorisponding interface. I'm faced with the delemma of dealing with
various implementations of the interface (i.e., CORBA, .Net, XML-RPC,
simple pointers...) and how it is abstracted. (Using CORBA, for
instance, means dealing with a high level of abstraction when using
the predefine interface.)

So with that in mind, I started using templates to abstract the *Impl
code:

template <class Intr, class refType, class valType>
class AImpl : public virtural Intr
{
private:
typedef typename refType::a_ptr a_ptr;
typedef typename refType::b_ptr b_ptr;
typedef typename valType::bool_type bool_type;

public:
// -=- these are the exposed interface methods to be called

virtual void foo(b_ptr pB)
{
// -=- do stuff like store pB for later use....
pB->run(this);
};

virtual bool_type bar(b_ptr pB)
{
return container.exists(pB);
};
};

struct aRefernceTypes
{
typedef AInterface::AInterface_ptr a_ptr;
typedef BInterface::BInterface_ptr b_ptr;
};

struct aValueTypes
{
typedef AInterface::BoolType bool_type;
}

typedef AImpl<AInterface,aReferenceTypes, aValueTypes> MyAImpl;

int main(ing argc,char** argv)
{
MyAImpl a;
}

When I use this technique I get something along the lines of:
main.cpp: In function `int main(int, char**)':
main.cpp:5: error: cannot declare variable `a' to be of type `MyAImpl'
main.cpp:5: error: because the following virtual functions are
abstract:
AInterface.h:25: error: virtual void
AInterface::foo(BInterface::BInterface_ptr)
AInterface.h:26 error: virtual Interface::BoolType
bar(BInterface::BInterface_ptr)

If I don't abstrace AInterface I get unresolved refernces to the
AInterface methods.

So:
On a specific point, why doesn't the templated AImpl compile/link
correctly? What are the fixes (or suggestions for further reading)?

On a more general point, I'm I on the right path in solving the
multiple interface/one algorithm problem or is leading me into a very
deep dark alley? Do I need to just abandon the legacy code and
redesign the software with interchanging interfaces in mind?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Allan W · Guest

[email]avatar (AT) hiwaay (DOT) net[/email] (TheGreatAvatar) wrote
[snip]