Question

I have several modules (mainly C) that need to be redesigned (using C++). Currently, the main problems are:

• many parts of the application rely on the functions of the module
• some parts of the application might want to overrule the behavior of the module

I was thinking about the following approach:

• redesign the module so that it has a clear modern class structure (using interfaces, inheritence, STL containers, …)
• writing a global module interface class that can be used to access any functionality of the module
• writing an implementation of this interface that simply maps the interface methods to the correct methods of the correct class in the interface

Other modules in the application that currently directly use the C functions of the module, should be passed [an implementation of] this interface. That way, if the application wants to alter the behavior of one of the functions of the module, it simply inherits from this default implementation and overrules any function that it wants.

An example:

• Suppose I completely redesign my module so that I have classes like: Book, Page, Cover, Author, … All these classes have lots of different methods.
• I make a global interface, called ILibraryAccessor, with lots of pure virtual methods
• I make a default implementation, called DefaultLibraryAccessor, than simply forwards all methods to the correct method of the correct class, e.g.
  • DefaultLibraryAccessor::printBook(book) calls book->print()
  • DefaultLibraryAccessor::getPage(book,10) calls book->getPage(10)
  • DefaultLibraryAccessor::printPage(page) calls page->print()
• Suppose my application has 3 kinds of windows
  • The first one allows all functionality and as an application I want to allow that
  • The second one also allows all functionality (internally), but from the application I want to prevent printing separate pages
  • The third one also allows all functionality (internally), but from the application I want to prevent printing certain kinds of books
• When constructing the window, the application passes an implementation of ILibraryAccessor to the window
  • The first window will get the DefaultLibraryAccessor, allowing everything
  • I will pass a special MyLibraryAccessor to the second window, and in MyLibraryAccessor, I will overrule the printPage method and let it fail
  • I will pass a special AnotherLibraryAccessor to the third window, and in AnotherLibraryAccessor, I will overrule the printBook method and check the type of book before I will call book->print().

The advantage of this approach is that, as shown in the example, an application can overrule any method it wants to overrule. The disadvantage is that I get a rather big interface, and the class-structure is completely lost for all modules that wants to access this other module.

Good idea or not?

Answer 1

The only thing I’d worry about is a loss of granularity, partly addressed by suszterpatt previously. Your implementations might end up being rather heavyweight and inflexible. If you’re sure that you can predict the future use of the module at this point then the design is probably ok.

It occurs to me that you might want to keep the interface fine-grained, but find some way of injecting this kind of display-specific behaviour rather than trying to incorporate it at top level.