这个问题让我思考:我们应该将"扁平比嵌套更好"的原则应用于数据还是代码?即使数据存在"逻辑树结构"?
在这种情况下,我认为这意味着将子代表作为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': ()} ]
Run Code Online (Sandbox Code Playgroud)
(我使用了元组,因为我不愿意给自己灵活地改变一个对象,直到这种灵活性证明它本身是有用的并且可以以清晰的方式使用.无论如何我永远不会None在这里使用而不是空序列,因为它使得复杂化逻辑,"特殊情况不够特别" - 在这里,它并不特别.)
当然这个更短,但树形结构模糊不清.这是否与"明确胜过隐性"相矛盾?
就个人而言,我发现"扁平比嵌套更好"的适用性有限,并且远不及禅宗最重要的方面.(当然,如果我不允许自己进行重要的嵌套,我无法做很多很好的函数式编程工作.)我怀疑"嵌套"的问题是当你理解信息时它需要上下文切换.我真的认为在遵循命令式逻辑时比解析数据或函数式代码更容易出问题 - 在这里更容易精神上命名嵌套块,并将其工作与外部上下文分开考虑.
怎么说你?