你的家谱应该使用定向关系。这样你就不会有循环了。

你应该把Atreides家族（现代的Dune，或古代的Oedipus Rex）作为一个测试案例。通过使用经过净化的数据作为测试用例，您不会发现错误。

不要删除所有断言，您仍然应该检查诸如某人是自己的父母或其他不可能的情况，并提出错误。如果不太可能的话，可能会发出警告，这样用户仍然可以检测到常见的输入错误，但如果一切都正确的话，它会起作用。

我会将数据存储在一个向量中，每个人都有一个永久整数，并将父母和孩子存储在个人对象中，其中所述int是向量的索引。这在几代人之间会很快（但在名字搜索等方面会很慢）。对象将按创建时的顺序排列。

我想，你有一些价值，可以唯一地识别一个人，你可以根据这个人进行检查。

这是一个棘手的问题。假设您希望将结构保持为树，我建议如下：

假设这样：A和自己的女儿有孩子。

A在节目中以A和B的身份加入节目。一旦扮演了父亲的角色，我们就称之为男朋友。

添加一个is_same_for_out（）函数，该函数告诉程序的输出生成部分，所有内部指向B的链接在数据表示时都应该指向a。

这将为用户带来一些额外的工作，但我想IT将相对容易实现和维护。

在此基础上，您可以进行代码同步A和B，以避免不一致。

这种解决方案肯定不是完美的，但却是第一种方法。

这就是为什么像“Go”这样的语言没有断言的原因之一。它们被用来处理那些你可能没有想到的案例，所有这些都太频繁了。你只应该断言不可能，而不仅仅是不可能。做后者会给断言带来坏名声。每次你输入assert（，走开十分钟，认真思考一下。

在你特别令人不安的案例中，在罕见但可能的情况下，这样的断言是假的，这是可以想象的，也是令人震惊的。因此，在你的应用程序中处理它，如果只是说“这个软件不是为处理你所呈现的场景而设计的”。

断言你的曾、曾、曾祖父是你的父亲是不可能的，这是合理的做法。

如果我是为一家被雇佣来测试你的软件的测试公司工作的话，我当然会提出这种情况。为什么？每一个年轻而聪明的“用户”都会做同样的事情，并对由此产生的“错误报告”津津乐道。

你应该关注真正为你的软件创造价值的东西。为一个消费者提供服务所花费的时间是否值得许可证的价格？可能不会。

我建议您向这位客户道歉，告诉他他的情况超出了您的软件范围，并向他退款。