10

We work with very old legacy system implemented in C++ with VC6 compiler. Now we are in the process of refactoring the code. We also switched to VC9 compiler.

We use an external proprietary framework, which is also legacy code and not unit testable. In order to make our code unit testable, we introduced interfaces and wrappers for the framework classes (hint: see “Working With Legacy Code” by Martin Fowler):

enter image description here

Now we depend on interfaces. The wrappers call the framework methods and we may happily use mocks in our unit tests.

And here we come to our problem...

The framework classes contain many methods that need to be wrapped and mocked. In order to achieve this goal, our supplier team wrote an API which generates interfaces, wrappers and mocks implementations with use of C++ Macros.

Example of wrapper header file:

class PlanWrapper : public IPlan
{
  // ... 
  WRP_DECLARE_DEFAULTS(FrameworkPlan); // macro
  WRP_DECLARE_CSTR_ATTR(FrameworkPlanLabel); // macro
  // ...
};

The Macro WRP_DECLARE_CSTR_ATTR is defined like this:

#define WRP_DECLARE_CSTR_ATTR(AttrName) \
    virtual bool set##AttrName (LPCTSTR Value_in); \
    virtual bool get##AttrName (CString& Value_out); \
    virtual bool unset##AttrName (); \
    virtual bool isSet##AttrName ()

Example of wrapper cpp file:

#include "StdAfx.h"

using namespace SomeNamespace;

WRP_IMPLEMENT_MODDICOM_DEFAULTS(FrameworkPlan)
WRP_IMPLEMENT_W_CSTR_ATTR (FrameworkPlan,FrameworkType1, FrameworkPlanLabel)
// ...

The Macro WRP_IMPLEMENT_W_CSTR_ATTR is defined like this:

#define WRP_IMPLEMENT_W_CSTR_ATTR(ClassName,AtrTypeObj,AttrName) \
    bool ClassName##Wrapper::set##AttrName (LPCTSTR Value_in) { \
            AtrTypeObj aValue = Value_in; \
        FrameworkLink<ClassName> convertedObj = NULL_LINK; \
        framework_cast(convertedObj, m_Object); \
        return convertedObj != NULL_LINK ? \
                       convertedObj->set##AttrName (aValue) : false; \
    }
    // ...

We have a bunch of even more complicated stuff, but I think you get the idea.

The problem with the API is that it is extremely complicated, not readable, not debuggable and not testable.

We would like to come up with a better mechanism for achieving the same goal. The idea was that we use some of the advanced features that came with new compiler like advanced templates, typelists, traits etc.

With templates we can almost achieve our goal, but we are stuck with the method names. We can generalize for types, but how do we deal with attribute names?

We also thought about creating a tool for automatically generating the wrapper + interfaces + mocks code. However, the API of our external framework is extremely complicated and writing such a tool would be very costly.

What do you think is the best way to solve such a problem? Maybe you already dealt with something like that and can provide good hints? We're looking forward to see your answers!

fortran
  • 74,053
  • 25
  • 135
  • 175
nowaq
  • 2,748
  • 19
  • 25

6 Answers6

1

Use Abstract factory instead macros to solve this problem.

class IApiFactory{
 virtual ISomeApi1* getApi1() =0;
 virtual ISomeApi2* getApi2() =0;
 .....
};

After implement this interface for your Normal api and moc api and pass the instance of your factory to your system like:

MySystem system( new NormalApiFactory );

or 

MySystem system( new MocApiFactory );

Your system must be declared as:

class MySystem{
public:
  MySystem( IApiFactory* factory );
};

In your factory you will return the normal api implementation or moc objects. Of course you could return factories "which will return other factories or objects" from your root factory.

AlexTheo
  • 4,004
  • 1
  • 21
  • 35
  • @BasileStarynkevitch 'The problem with the API is that it is extremely complicated, not readable, not debuggable and not testable.' 'We would like to come up with a better mechanism for achieving the same goal. The idea was that we use some of the advanced features that came with new compiler like advanced templates, typelists, traits etc.' I just suggest an standard mechanism to solve this problem. – AlexTheo Dec 14 '11 at 11:29
  • @AlexTheo Sorry, maybe the description can be a bit confusing. By saying "the API" I meant the MACROS that we currently use to generate the Wrappers. This is the "problem" that we would like to replace with something nicer/better/more robust. – nowaq Dec 14 '11 at 12:28
1

I think I would go with a code generation tool. I would probably make a few simple utility programs: one for generating an interface corresponding to a class of your legacy framework, one for generating the wrapper and one for generating the mock object (or at least a skeleton).

This implies having some way to parse the code of your legacy framework. I would have a look at Clang, or perhaps simply run ctags on the source file and treat the resulting tags.

Luc Touraille
  • 79,925
  • 15
  • 92
  • 137
0

If the code base is large enough (i.e. several hundred thousands lines of C++), and if you can compile it with GCC (a recent version, i.e. 4.6) you could perhaps consider making a specific GCC plugin, or a MELT extension. (MELT is a high-level domain specific language to extend GCC). However such GCC customization takes a significant amount of efforts (weeks, not hours, of work).

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
0

I like the code generator. You may create a dictionary of all things to be wrapped, it takes time, then use a simple tool to generate the code. Beside the code, you also get a clear reference of the legacy system, a guide to replace it some later.

pinxue
  • 1,736
  • 12
  • 17
0

Our DMS Software Reengineering Toolkit is a program transformation tool that reads source code and carries out arbtitrary transformations on it.

DMS, with its C++ Front End (VC6 and more modern Visual Studio capable), it could probably be used to read the header files for the components to be mocked, and generate the mocks.

DMS has been used to carry out massive transformations on C++ code, especially involving interface changes and shuffling interfaces around in various ways. See one of my technical papers, Re-engineering C++ Component Models Via Automatic Program Transformation.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
0

There is a way to structurize your code generation in completely controlled fashion and still maintain all the freedom of generate what ever difficult API stuff you need.

If you use Visual Studio (2005 at least, but preferably 2008 or 2010) you can use this T4 Team's mentioned way of structurized code generation - that is based on T4 and XML only:

http://blogs.msdn.com/b/t4/archive/2011/11/30/some-nice-new-getting-started-with-t4-videos.aspx

I am the innovator and lead architect of that ADM methodology and author of that blog http://abstractiondev.wordpress.com/

Unfortunately I don't have concrete case to link to match yours, but I'm happy to work the solution for you (and in case you want to benefit the community, publish a case from that).

Kallex
  • 498
  • 2
  • 10