3

我正在解析一些字符串，这些字符串包含对象信息以及对象的一些依赖项或要求。

这是用于产品配置的，对象是构成产品构建的组件。想象一下，当您通过列表构建汽车、计算机或其他任何具有需要您选择某些组件才能获得其他组件的组件时。这是我试图在我的应用程序中创建的逻辑。

我的应用程序向用户展示了一个 treeView 组件，其中包含从 excel 文件加载的对象列表。我正在尝试创建一个交互式对象列表，该列表可以根据节点所代表的对象之间的依赖关系正确启用和禁用 treeView 的节点。对象列表表示构建的配置。因此，对象是构成最终产品的组件，并且对于可以为任何给定构建选择哪些组件或对象具有限制。

这是包含我要为其编写逻辑的依赖项的行的示例格式：

objectID_y1234_y1233_n2345

  • objectID是此对象（组件）的 id，是一个 4 位数字，极少数情况下对象的 id 中有一个字母，例如：12a4

  • y1234表示此对象需要选择 id 为 1234 的对象才能处于活动状态。

  • y1233表示此对象需要选择 id 为 1233 的对象才能处于活动状态。

    由于 y1234 和 y1233 在它们的 ID 号中共享相同的前两位数字，因此创建了一个 or 条件。

    因此，此对象需要选择对象 1234 或 1233，而不是同时选择两者。

  • n2345 means this object is not active when object 2345 is selected.

列出的第一个依赖项始终以“y”或“n”开头，因此您永远不能拥有 objectID_1234_n2345_y1235，但您可以拥有 objectID_y1234_1235_n2345。

此外，如果条件是“或”条件，则不能有 y1234_n1233，它要么都具有 y，要么都具有 n。

更多可能的格式：

  1. objectID_y1234_2345
    这是说明对象需要选择对象 1234 和对象 2345 才能使该对象处于活动状态。

  2. objectID_n1234_2345_y3456
    此状态 objectID 要求不选择 1234 和 2345 并选择 3456 以使该对象处于活动状态。

  3. objectID_n1234_n1233
    与 y1234_y1233 不同，如果使用 n，则条件始终为“and”，因此这意味着无法选择 1234 和 1233 以使该对象处于活动状态。

如果有不清楚的地方，请随时询问更多信息/解释。我试图尽可能清楚地解释这一点，因为依赖关系很容易变得混乱。我没有列出语句的所有可能组合，因为它们没有长度限制，而只是由带有对象 ID 的更长或多个“或”和“和”条件组成。

正在发生的事情的大图：

我有一个 objectID 的树形视图，当您选择一个对象时，您必须停用冲突的对象并激活或现在可以选择的对象。

依赖的目的：

依赖项必须回答两个问题......

1：哪些对象不能被选中来激活这个对象？

2：必须选择哪些对象才能使该对象处于活动状态？

我的问题/问题：

我发现这些数据非常脆弱，有时对象会相互依赖，从而使两个对象都失效，并且两者都无法被选中。

例子：

ID1234_y2345

ID2345_y1234

这导致 1234 或 2345 都不是活动的，因为在开始时两者都被停用，因为不满足要求（依赖关系）。

如果有人有想法可以更改表示依赖项的语法或格式，我可以这样做。我只是还没有找到一种替代方法来满足要求而不会导致更多的复杂性或问题。

最终，我正在寻找一种方法来解决这个问题并提出一个可行的解决方案。一段时间以来，我一直在尝试实施解决方案，但到目前为止，我的所有尝试都失败了。我尝试了各种递归和非递归解决方案。我可能错了，但我几乎觉得这是神经网络可以做的事情，因为我基本上是想让计算机在这里自己思考。

我一直在尝试从我需要做的所有事情的列表开始，然后实施一个满足列表的解决方案，但我最终发现了更多的问题并添加到列表中，所以我永远不会涵盖所有的可能性和那里可能还有更多我还没有发现。总的来说，我已经能够在某些时候正确地停用和激活，但它并不总是可靠的，它需要是。

当前逻辑

在树中，相同类型的组件共享相同的 2 个前导字符，因此如果 1234、1233 和 1245 在一个组中并且用户选择 1234，我将该组视为单选按钮。因此，将 1234 添加到跟踪所选组件的列表中，并将 1233,1245 添加到另一个禁用组件列表中。然后通过检查每个组件并确保它被禁用或启用，这取决于它现在是否满足它的要求来更新整个树。但是，如果我在检查时必须禁用另一个组件，目前我会重新检查树，这是非常低效的，因为它可能会继续这样做一段时间。我认为递归可能会更好地工作，但是却弄得一团糟，很难调试并且仍然存在太多问题。

对于检查组件列表，我仍然认为递归是一种方式，因为当我选择一个组件时，我需要禁用其他不可用的组件，然后检查我禁用的组件，然后检查任何因我禁用的组件禁用等等...

示例：如果我禁用 1234 并且 1890 需要 1234，我现在禁用 1890。但现在 1770 需要 1890，所以我禁用 1770。然后如果某些东西需要 1770，我需要禁用它等等...

感谢所有帮助和建议。

4

1 回答 1

0

一个有效的解决方案，已经取代我原来的逻辑。

原始逻辑让应用程序检查受用户选择的节点影响的所有节点。节点状态（禁用、启用、选择）由用户选择的节点控制，并且每次用户在树视图中选择一个组件时都会对其进行验证。

解决方案：

通过重新思考我的方法，我为应用程序提出了以下逻辑，该应用程序完成了确保强制执行组件的依赖关系的任务：

当用户选择一个组件时，应用程序执行以下步骤：

  • 检查组件是否存在与其不兼容的对象，并检查用户是否选择了任何组件。

    • 如果发现了不兼容的对象，它会向用户提示一条信息性消息，说明用户选择的哪个组件与用户试图选择的组件冲突。

  • 检查该组件是否有该组件所需的其他组件，并检查这些组件是否已被选中。

    • 如果尚未选择所有必需的组件，则会提示用户一条消息，说明还需要选择哪些组件，并将所选组件的文本变为红色并在树视图中选择它。
    • 如果满足所有要求，则选择该组件并且如果该组件具有红色文本，则该文本将改回默认的黑色。

注意：提示将是可选的，因为它们被记录在界面上的日志中，允许用户在需要时参考它们。

结论：

该解决方案允许配置器确保满足组件的依赖性和要求。尽管更新节点是最初的意图，但我意识到在最初的逻辑中我没有想到如何帮助用户找出组件被禁用的原因。使用这种新方法，配置器提供了丰富的信息，不会让用户感到困惑。

当然，可以创建一个像原始概念一样的配置器，但鉴于我的经验和各种工具，这个其他解决方案提供了一个我的用户更满意的工作应用程序。

于 2012-09-12T23:30:21.367 回答