C++ 'wrapper class' for XML library

So I've been attempting to create some classes around the xerces XML library so I can 'hide' it from the rest of my project the underlying xml library stays independent from the rest of my project.

This was supposed 开发者_如何学Goto be a fairly easy task, however it seems entirely impossible to hide a library from the rest of a project by writing some classes around it.

Have I got the wrong approach or is my 'wrapper' idea completely silly?

I end up with something like this:

DOMElement* root();  //in my 'wrapper' class, however this DOMElement is part of the xerces library, at this point my 'wrapper' is broken.  Now I have to use the xerces library everywhere I want to use this function.

Where is my thinking gone wrong?

---

I would recommend avoiding the wrapper in the first stage. Just make sure that the layers and their borders are clear, i.e. the network layer takes care of serializing/deserializing the XML, and from there on you only use your internal types. If you do this, and at a later stage you need to replace xerces with any other library, just replace the serialization layer. That is, instead of wrapping each XML object, just wrap the overall operation: serialize/deserialize.

---

Writing your own abstract interface for a library is not a silly idea IF you have plan to change or to have the possibility to change the library you are using.

You should not rely on your library object to implement your wrapper interface. Implement your own structure and your own function interface. It will ease a lot of work when you will want to change how xml is implemented (eg: change library).

One example of implementation:

class XmlElement
{
    private:
    DOMElement element; // point to the element of your library

    public:
    // Here you define how its public interface.
    // There should be enough method/parameter to interact
    // with any xml interface you will use in the future
    XmlElement getSubElement(param)
    {
        // Create the Xmlelement
        // Set the DOMElement wanted
        // return it
    }
}

In your program you will see:

void function()
{
    XmlElement root();
    root.getSubElement("value"); // for example
}

Like that no DOMElement or their function appear in the project.

---

As I mentioned in my comments, I would take a slightly different approach. I would not want my codebase to be dependent on the particular messaging format (xml) that I am using (what if for example you decide to change the xml to something else later?) Instead I would work with a well defined object model and have a simple encoder/decoder to handle the conversion to XML string and vice versa. This encode/decoder would then be the bit that I would replace if the underlying wire format changed.

The decoder would take in the data read from the socket, and produce a suitable object (with nested objects to represent the request) and the decoder would take a similar object and generate the XML from it. If performance is not a primary concern, I would use a library such as TinyXML which is quite lightweight - heck, you can strip that down even further and make it more light weight...