Question

所以我一直在尝试围绕xerces XML库创建一些类，这样我就可以从项目的其余部分“隐藏”它，底层的xml库与我项目的其余部分保持独立。

这应该是一个相当容易的任务，但是通过在它周围写一些类来隐藏项目的其余部分似乎是完全不可能的。

我的做法是错误的，还是我的'包装'想法完全愚蠢？

我最终得到这样的东西：

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.

我的想法出了什么问题？

Answer 1

如果您计划更改或有可能更改您正在使用的库，那么为库编写自己的抽象接口并不是一个愚蠢的想法。

您不应该依赖库对象来实现您的包装器接口。实现自己的结构和自己的功能接口。当您想要更改xml的实现方式时，它将简化大量工作（例如：更改库）。

实施的一个例子：

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
    }
}

在您的计划中，您将看到：

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

就像没有DOMElement或它们的功能出现在项目中一样。

Answer 2

我建议在第一阶段避免使用包装器。只需确保图层及其边框清晰，即网络层负责序列化/反序列化XML，从那里您只使用内部类型。如果您这样做，并且稍后您需要将xerces替换为任何其他库，只需替换序列化层。也就是说，不是包装每个XML对象，而是包装整个操作：serialize / deserialize。

Answer 3

正如我在评论中提到的，我会采取略微不同的方法。我不希望我的代码库依赖于我正在使用的特定消息传递格式（xml）（例如，如果您决定稍后将xml更改为其他内容？）相反，我将使用定义良好的对象模型并具有一个简单的编码器/解码器来处理转换为XML字符串，反之亦然。如果底层有线格式发生变化，那么这个编码/解码器将被替换。

解码器将接收从套接字读取的数据，并生成合适的对象（具有表示请求的嵌套对象），解码器将采用类似的对象并从中生成XML。如果性能不是主要考虑因素，我会使用像TinyXML这样非常轻量级的库 - 哎呀，你可以进一步降低性能并使其更轻量级......

用于XML库的C ++'包装类'

3 个答案: