“扁平比嵌套更好”——对于数据和代码？ [关闭]

This https://stackoverflow.com/questions/4372073/traversing-and-modifying-a-tree-like-list-of-dict-structure/4372174#4372174这个问题让我思考：我们是否应该将“扁平优于嵌套”的原则应用于数据和代码？即使数据存在“逻辑树结构”？

在这种情况下，我想这意味着将子项表示为 ID 列表，而不是实际的子项列表，所有节点都在一个列表中：

[ {'id': 4, 'children': ()},
  {'id': 2, 'children': (1, 7)},
  {'id': 1, 'children': (6, 5)},
  {'id': 6, 'children': ()},
  {'id': 5, 'children': ()},
  {'id': 7, 'children': (3,)},
  {'id': 3, 'children': ()} ]

（我使用元组是因为我不喜欢给自己提供改变对象的灵活性，直到这种灵活性证明自己是有用的并且可以以明确的方式使用。无论如何，我永远不会使用None这里而不是空序列，因为它使逻辑复杂化，并且“特殊情况不够特殊” - 在这里，它根本不特殊。）

当然，这更短，但树结构变得模糊。这是否与“显式优于隐式”相矛盾？

就我个人而言，我发现“扁平优于嵌套”的适用性有限，而且远不是禅宗最重要的方面。 （当然，如果我不允许自己进行大量嵌套，我就无法做很多出色的函数式编程事情。）我怀疑“嵌套”的问题在于，当您理解信息时，它需要上下文切换。我真的认为，在遵循命令式逻辑时，这比解析数据或函数式代码时更成问题——在这种情况下，更容易在心里命名嵌套块，并与外部上下文分开考虑其工作原理。

你说什么？

这是一个完全主观的问题。答案是“这取决于情况”。

这取决于数据的主要用途。如果您必须不断引用嵌套结构，那么以这种方式表示它是有意义的。如果除了构建嵌套结构时从不引用平面表示，那么为什么要使用平面结构呢？

“平面”表示是关系数据库模型的基础之一：每种类型的数据都存在于该类型的表中，并且项目之间的任何关系都包含在单独的表中。这是一个有用的抽象，但有时很难在代码中使用。另一方面，处理特定类型的所有数据是微不足道的。

例如，考虑一下，如果我想在示例数据中查找 id 2 的记录的所有后代。如果数据已经在层次结构中（即本机表示是“嵌套”结构），那么定位记录 id 2 然后遍历其子项、子项的子项等就很简单了。

但是，如果本机表示是按顺序显示的，那么我必须遍历整个数据集来创建层次结构，并且then找到记录 2 及其子记录。

所以，正如我所说，“这取决于情况”。