让多线程程序的两个“深层”部分相互交谈的模式是什么？

Question

我在设计、重构或“分类”中遇到了这个普遍问题：

我有一个现有的多线程 C++ 应用程序，它使用许多插件库来搜索数据。使用当前的搜索接口，给定的插件接收一个搜索字符串和一个指向 QList 对象的指针。在不同的线程上运行，该插件会搜索各种数据源（本地和网络）并将感兴趣的对象添加到列表中。当插件返回时，仍然在单独线程上的主程序将此数据添加到本地数据存储（进行进一步处理），并使用互斥锁保护此插入点。因此每个插件都可以异步返回数据。

基于 QT 的插件库基于消息传递。有相当多的插件已经为应用程序编写和测试过，它们工作得很好。

我想编写更多插件并利用现有应用程序。

问题是新插件需要应用程序提供更多信息。他们在搜索时需要间歇性地访问本地数据存储本身。所以为了得到这个，他们需要直接或间接访问存储数据的哈希数组和保护对存储的多次访问的互斥锁。我假设通过在“目录”对象中添加一个额外的方法来封装访问。

我可以看到三种编写这些新插件的方法。

1. 加载插件时，传递它们 指向我的“目录”的指针 开始。这成为一个额外的， 新的“隐形”界面 插件。这似乎又快又容易， 根据OO完全错误但是 我看不到未来的问题会是什么。

2. 将方法/消息添加到 现有的界面，所以我有一个 第二个功能可能是 需要新的插件库， 该消息将传递一个指向 插件的目录。这 对于插件来说很容易，但它 会使我的主要代码复杂化 似乎总体上很糟糕。

3. 重新设计插件界面。 根据 OO，这似乎是“最好的”， 可能有其他额外的好处，但 将需要各种 重写。

所以，我的问题是

A.谁能告诉我选项 1 的具体危险？

B.是否有适合此类问题的已知模式？

编辑1：

调用插件例程的典型函数如下所示：

elsewhere(spec){
    QList<CatItem> results;
    plugins->getResult(spec, &results);
    use_list(results);
}

...
void PluginHandler::getResults(QString* spec, QList<CatItem>* results)
{
    if (id->count() == 0) return;
    foreach(PluginInfo info, plugins) {
        if (info.loaded)
            info.obj->msg(MSG_GET_RESULTS, (void*) spec, (void*) results);
    }
}

这是一个重复的代码。我宁愿延长它也不愿破坏它。

Answer 1

为什么“根据 OO 完全错误”？如果您的插件需要访问该对象，并且它不违反您想要保留的任何抽象，那么它就是正确的解决方案。

在我看来，当你决定你的插件需要访问列表本身时，你似乎就搞砸了你的抽象。您刚刚炸毁了整个应用程序的架构。您确定需要访问实际列表本身吗？为什么？你需要什么？能否以更明智的方式提供这些信息？一个不会 1) 增加对共享资源的争用（并增加微妙的多线程错误的风险，如竞争条件和死锁），以及 2) 不会破坏应用程序其余部分的架构（特别是保留分离在列表与其客户端之间，以允许异步）

如果您认为这是糟糕的 OO，那是因为您从根本上试图做的事情（违反应用程序的基本架构），而不是如何。

Answer 2

嗯，选项 1 最终是选项 3。您正在重新设计插件 API 以接收来自主应用的额外数据。

这是一个简单的重新设计，只要“目录”实现良好并隐藏哈希和互斥后备存储的每个实现细节，就不错，并且可以很好地满足 IMO 的目的。

现在，如果目录泄露了实现细节，那么您最好使用消息来查询商店，接收带有所需数据的响应。

Answer 3

抱歉，我刚把你的问题重新看了 3 遍，我觉得我的回答可能太简单了。

你的“目录”是一个独立的对象吗？如果没有，您可以将其包装为自己的对象。目录应该是完全安全的（包括线程安全的）——或者更好的是不可变的。

完成此操作后，将目录传递给新插件将是完全有效的 OO。如果您担心它们会通过很多层，您可以为目录创建一个工厂。

抱歉，如果我仍然误解某些内容，但我认为这种方法没有任何问题。但是，如果您的目录是您无法控制的对象，例如数据库对象或集合，那么您确实必须将其封装在您可以通过漂亮、干净的界面控制的东西中。

如果您的目录被您的程序中的许多部分使用，您可能会查看一个工厂（它最简单地降级为单例）。使用工厂，您应该能够使用 Catalog.getType("Clothes"); 召唤您的目录。管他呢。这样一来，您就可以将相同的对象分发给所有想要的人，而无需传递它。

（顺便说一下，这与单例非常相似，但将其编码为工厂会提醒您几乎肯定会有不止一个——还要记住允许 Catalog.setType("Clothes", .. .); 用于测试。