我正在解析一些包含对象信息的字符串，其中包含对象的一些依赖关系或要求。
这适用于产品配置，对象是构成产品构建的组件。想象一下，当你通过一个列表来建造一辆汽车，一台电脑或其他任何需要你选择某些组件以便获得其他组件的组件时。这是我试图在我的应用程序中创建的逻辑。
我的应用程序向用户提供了一个treeView组件，其中包含从excel文件加载的对象列表。我正在尝试创建一个交互式对象列表，根据节点所代表的对象之间的依赖关系，正确地启用和禁用treeView节点。对象列表表示构建的配置。因此，对象是构成最终产品的组件，并且对于任何给定构建可以选择哪些组件或对象有限制。
以下是包含我尝试为其编写逻辑的依赖项的行的示例格式：
objectID_y1234_y1233_n2345
objectID 是此对象（组件）的ID，是一个4位数字，极其罕见的情况是它在对象的id中有一个字母：12a4
y1234 表示此对象需要选择ID为1234的对象才能激活。
y1233 表示此对象需要选择ID为1233的对象才能激活。
由于y1234和y1233在其ID号中共享相同的前两位数，因此会创建一个或条件。
因此，此对象需要选择对象1234或1233，而不是两者都被选中。
n2345 表示选择对象2345时此对象无效。
列出的第一个依赖项始终以＆＃34; y＆＃34;开头。或者＆＃34; n＆＃34;所以你永远不会有objectID_1234_n2345_y1235，但你可以拥有objectID_y1234_1235_n2345。
如果条件是＆＃34;或＆＃34;条件你不能有y1234_n1233，要么两者都有y，要么两者都有n＆＃39; s。
许多可能的格式中的一些：
objectID_y1234_2345
这说明对象要求对象1234和对象2345被选中以使该对象处于活动状态。
objectID_n1234_2345_y3456
这表明objectID要求不选择1234和2345，并且要选择3456以使该对象生效。
objectID_n1234_n1233
与y1234_y1233不同，如果使用n，条件总是＆＃34;和＆＃34;所以这意味着无法选择1234和1233来激活此对象。
如果不清楚，请随时询问更多信息/解释。我试图尽可能清楚地解释这一点，因为依赖关系可能很容易混淆。我没有列出所有可能的陈述组合，因为它们没有长度限制，但只包括更长或更多的＆＃34;或＆＃34;和＆＃34;和＆＃34;具有对象ID的条件。
我有一个对象ID的树视图，当你选择一个对象时，你必须取消激活冲突对象并激活或现在可以选择的对象。
依赖关系必须回答两个问题......
1：无法选择哪个对象才能激活此对象？
2：必须选择哪个对象才能激活此对象？
我发现这些数据非常脆弱，有时候对象会依赖于彼此的依赖关系，从而无法激活这两个对象。
示例：
ID1234_y2345
ID2345_y1234
这导致1234或2345都不活动，因为在启动时两者都被取消激活，因为不满足要求（依赖性）。
如果有人有想法可以改变表示依赖关系的语法或格式，我可以这样做。我还没有找到符合要求的替代方法，而不会导致更多的复杂性或问题。
最终，我正在寻找一种可以解决这个问题的方法，并提出一个可行的解决方案。我一直试图实施一段时间的解决方案，到目前为止我的所有尝试都失败了。我尝试过各种递归和非递归解决方案。我可能错了，但我几乎觉得这是神经网络可以做的事情，因为我基本上是想让计算机在这里思考。
我一直在尝试从我需要做的所有事情的列表开始，然后实现一个满足列表的解决方案，但我最终找到了更多的问题，因为我去了并添加到列表所以我从来没有覆盖所有的可能性，可能还有更多我尚未发现。总的来说，我已经能够在某些时候正确地取消激活和激活，但它始终不可靠并且需要它。
在树中，相同类型的组件共享相同的2个前导字符，因此如果1234,1233和1245在一个组中并且用户选择1234，则将该组视为单选按钮。因此，1234添加到跟踪所选组件的列表中，并将1233,1245添加到另一个禁用组件列表中。然后通过检查每个组件并确保它被禁用或启用来更新整个树，具体取决于它是否满足它的要求。但是，如果我必须在检查时禁用另一个组件，目前我再次检查树，这是非常低效的，因为它可以继续这样做一段时间。我认为递归可能效果更好，但是得到了一个很难调试的混乱，但仍然存在太多问题。
为了检查组件列表，我仍然认为递归是这样的，因为当我选择一个组件时，我需要禁用其他不可用的组件，然后检查我禁用的组件，然后检查由于我禁用的那些等等......
示例：如果我禁用1234并且1890需要1234，我现在禁用1890.但现在1770需要1890所以我禁用1770.然后如果某些东西需要1770我需要禁用它等等...
感谢所有帮助和建议。
答案 0 :(得分：0)
一种有效且已经实施的解决方案，取代了我原来的逻辑。
原始逻辑让应用程序检查受用户选择的节点影响的所有节点。节点状态（禁用，启用，选择）由用户选择的节点控制，并在每次用户在treeView中选择组件时进行验证。
通过重新思考我的方法，我为应用程序提出了以下逻辑，它完成了确保组件的依赖性得到强制执行的任务：
当用户选择一个组件时，该应用程序将执行以下步骤：
检查组件是否与其不兼容的对象，并检查用户是否已选择任何组件。
检查组件以查找此组件所需的其他组件，并检查是否已选择这些组件。
注意： 提示将是可选的，因为它们被记录在界面上的日志中，允许用户根据需要返回它们。
此解决方案允许配置程序确保满足组件的依赖性和要求。虽然节点更新是最初的意图，但我在原始逻辑中意识到我没有想到如何帮助用户弄清楚组件被禁用的原因。使用这种新方法，配置器可以提供信息，不会让用户感到困惑。
当然可以像原始概念一样创建配置器，但鉴于我的经验和各种工具，这个其他解决方案提供了一个我的用户更满意的工作应用程序。