Question

I have been using two libraries, SFML and Box2D, while at the same time taking great pain to ensure none of their functions or classes are exposed in the main body of my code, hiding them behind classes that serve little more than to act as a mediator between my code and the library itself. My mediators take the following form:

    class MyWindow{
    public:
        // could be 10 or so functions like below
        int doSomething(int arg){
           return library_window->doSomething(arg);
        };
    private:
        library::window * library_window;
    };

The benefit to this, at least what I’ve been told, is that my main code body is not reliant upon the library, in such a way that if it changes or I choose to use a different one, say SDL or OpenGL in place of SFML or something, I can switch by merely amending the mediator classes. But the pain of having to code an access point into every feature I want to use is painful and repetitive…

Is this really how professional programmers are supposed to treat external libraries? And is it worth it?

Am I even doing this right?

Answer 1

The problem with the wrapper technique you’re describing is that your wrapper is transparent (in the true sense of that word) — every method in the library is still visible to you through the wrapper, with the same semantics, same preconditions, etc. You can “see right through” your wrapper.

A transparent wrapper like that is useful to you only if you someday switch the underlying library to something that has identical semantics, or at least very nearly identical semantics. Consider this example. Let’s say the library was the std::fstream, and your application needed to read and write files, and lets say that you diligently wrote a wrapper:

class MyFile {
    std::fstream* fst;
public:
    void writeData(void* data, size_t count) {
        fst->write((const char*) data, count);
    }
    void readData(void* buffer, size_t count) {
        fst->read((char*) data, count);
    }
    // etc, etc.
};

Now let’s say you want (or need) to switch to asynchronous I/O with non-blocking reads and writes. There’s simply no way that your transparent wrapper is going to help you make that transition. The asynchronous read requires two methods, one to start the read operation and one to confirm that the read has completed. It also requires a commitment from the application that the buffer won’t be used in between those two method calls.

When all is said and done, a library interface wrapper is useful only when very carefully designed to not be transparent (good interfaces are opaque). Furthermore, to be useful, the library you are wrapping must be something that you are intimately familiar with. So, boost::filesystem can “wrap” the pathnames for both DOS and Unix because the authors know intimately POSIX, UNIX and DOS pathnames and are designing the “wrapper” to effectively encapsulate those implementations.

From what you’ve described, it seems to me that your effort is going to end up wasted. Simple is better than complicated, and unless the wrapper is really encapsulating something (i.e., hiding the underlying library), direct is better than indirect.

That’s not a license to write spaghetti — your application still needs structure and isolation of the major components (e.g., isolate the UI from the actual calculations/simulations/document that your application provides). If you do that right, swapping the library some day will be a manageable task without any wrapper code.