c++ - 如何对部分可重用算法进行正确的设计/架构？

Question

Closed. This question needs to be more focused。它当前不接受答案。












想改善这个问题吗？更新问题，使其仅关注 editing this post的一个问题。

6年前关闭。



Improve this question




对于冗长的解释，我感到非常抱歉，但这是正确理解所必需的。

我正在研究用于工业任务的计算机视觉算法。计算机视觉算法往往非常复杂。通常，它们涉及调用(至少是)许多较简单的算法(也都不简单)。这些调用形成一定的层次结构:较大的任务调用一些较小的任务，然后依次调用较小的任务，依此类推。

让我们以典型的计算机视觉任务为例:在特定条件下在图像中查找对象。这是一项应在许多不同应用程序中执行的任务。每个应用程序都有其自己的条件集，因此不可能创建适用于所有条件的单一算法。但是它们非常相似。通常，足以替换一个或两个较低级别的功能。例如:使用不同的方法来检测图像中的兴趣点。

这是一个问题:对于每个新应用程序，我不得不从一个现有应用程序中复制整个代码，并修改相关部分，这是一种不好的做法。我正在尝试通过创建可在所有应用程序中使用而无需更改代码本身的算法系统来消除这些重复。这是系统必须处理的问题列表(至少是我到目前为止确定的问题):

1)提供给主要算法的参数应该能够设置系统内部的“算法流”，即它们确定使用哪种较低级别的算法以及如何使用

2)执行相同任务的不同子算法可能需要不同的输入。一个可能需要一个整数数组，另一个可能需要一对整数，依此类推...更高级别的算法应该忽略将一个子算法替换为另一个子算法。这意味着他们不应该知道收到了哪些参数并将其传递给子算法。子算法的输出也是如此。如果使用不同的子算法组合，则可能会有所不同

3)系统必须是可扩展的。如果新的子算法可用(例如:找到兴趣点的另一种方法)，系统应该可以调用它。我知道目前可能无法避免更改，但我希望将更改降到最低。而且在任何情况下，系统都应该能够使用先前的参数集以相同的方式工作。

4)系统必须是可调试的。系统的最终用户应该有合理的方法来转储有关系统中“算法流”的调试信息，以便算法开发人员能够重新创建这种情况。考虑要求(3)并不是那么简单。

5)应该有合理的方法对算法流程进行完整性检查。

6)我不会抛出异常，但是应该有合理的方法来返回每个算法的成功/失败状态。同样，由于要求(3)，这并不容易。

7)这个比“必须拥有”更“具有拥有”，但这可能很重要。一些计算可以通过多个子算法来执行。例如，对于多个不同的任务，可能(或可能不需要)计算图像中的梯度。可以选择存储这些计算的结果以便以后重用。

我为此创建了某种解决方案，但远非如此。您对应该如何做有什么建议？

使用语言:C++

谢谢

最佳答案

我只会使用一些经过尝试的真实设计模式。

使用strategy pattern表示您可能希望换成其他选择的算法。

使用factory根据某些输入参数或运行时上下文实例化不同的算法(策略)实例-我是prototype factory的支持者，在该表中，您在某些查找表中具有每个对象的“惰性”实例，并且基于传递的键您可以请求所需副本的副本。我喜欢它主要是因为它最容易扩展-您甚至可以在运行时将新配置的原型(prototype)实例添加到这样的工厂。

请注意，相同的“策略”模型并不一定要适用于所有情况-听起来您可能有一些较高级别/模糊的操作，然后将这些较低级别/详细操作组合或链接在一起。高级操作可以是抽象对象的一种，而详细算法是更具体的策略实例。

至于各种算法的输入，如果不同算法之间的输入差异很大，则可以使用可扩展对象(例如字典)作为参数，以便每种算法都可以仅使用所需的参数，而忽略其他用于操作的参数。如果字典在操作期间是可修改的，这还将允许上游算法为下游算法添加参数。键值对非常容易转储到日志或在调试器中查看。

如果每个策略实例都具有唯一的语义标识符，则可以轻松调试实例化并链接在一起的算法。 (我使用的音频DSP库具有转储已配置音频处理器整个链的描述的功能，非常方便)。

如果您使用具有策略模式和可扩展参数的系统，那么您还应该能够将共享算法与特定于应用程序的算法分离开来，但是仍然具有用于实例化和运行它们的相同基本框架。

hth

关于c++ - 如何对部分可重用算法进行正确的设计/架构？ ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23798675/

上一篇：c - 为什么我的宏中的 `_Generic` 关键字不起作用？

下一篇：c - Bash 返回简单 C 程序的权限被拒绝

相关文章：

architecture - N 层架构中的事务边界

c++ - 在作用域生存期之前调用C++析构函数

c - 指针和数组的奇怪行为

c - 循环中无法理解的问题(Clion 上的 C)

c - OpenSSL:如何找出当前 SSL 连接数？

validation - 您在哪里进行验证？

c++ - (C++) 与结构和函数参数有关的简单问题

c++ - 使用 "pointer to volatile"是否始终阻止编译器优化？

c++ - 使用 C++11 future :std::async 崩溃的嵌套调用:编译器/标准库错误？

ruby-on-rails - 合并多个 Rails 应用程序，并能够启用/禁用每个应用程序

Answer 1

我只会使用一些经过尝试的真实设计模式。

使用strategy pattern表示您可能希望换成其他选择的算法。

使用factory根据某些输入参数或运行时上下文实例化不同的算法(策略)实例-我是prototype factory的支持者，在该表中，您在某些查找表中具有每个对象的“惰性”实例，并且基于传递的键您可以请求所需副本的副本。我喜欢它主要是因为它最容易扩展-您甚至可以在运行时将新配置的原型(prototype)实例添加到这样的工厂。

请注意，相同的“策略”模型并不一定要适用于所有情况-听起来您可能有一些较高级别/模糊的操作，然后将这些较低级别/详细操作组合或链接在一起。高级操作可以是抽象对象的一种，而详细算法是更具体的策略实例。

至于各种算法的输入，如果不同算法之间的输入差异很大，则可以使用可扩展对象(例如字典)作为参数，以便每种算法都可以仅使用所需的参数，而忽略其他用于操作的参数。如果字典在操作期间是可修改的，这还将允许上游算法为下游算法添加参数。键值对非常容易转储到日志或在调试器中查看。

如果每个策略实例都具有唯一的语义标识符，则可以轻松调试实例化并链接在一起的算法。 (我使用的音频DSP库具有转储已配置音频处理器整个链的描述的功能，非常方便)。

如果您使用具有策略模式和可扩展参数的系统，那么您还应该能够将共享算法与特定于应用程序的算法分离开来，但是仍然具有用于实例化和运行它们的相同基本框架。

hth