我有一个名为Path 的类，在专用模块Path.py 中定义了大约10 个方法。最近我需要为 Path 再写 5 个方法，但是这些新方法非常晦涩和技术性，而且 90% 的时间它们是无关紧要的。
把它们放在哪里比较好，这样它们的上下文就很清楚了？当然我可以把它们和类定义放在一起，但我不喜欢这样，因为我喜欢把重要的东西和晦涩的东西分开。
目前我将这些方法作为函数定义在一个单独的模块中，只是为了将它们分开，但最好将它们作为绑定方法。 （目前他们将Path 实例作为显式参数。）
有人有什么建议吗？
【问题讨论】：
get_item_with_end_node，假设路径具有所谓的“结束节点”，则从路径中获取项目。在我的项目中，绝大多数路径都没有结束节点。
如果方法与路径相关——无论多么晦涩——我认为它应该驻留在类本身中。
如果您在多个地方都有与路径相关的功能，则会导致问题。例如，如果您想检查某些功能是否已经存在，新程序员如何知道检查其他不太明显的地方？
我认为一个好的做法可能是按重要性对函数进行排序。正如您可能听说过的那样，有些人建议首先放置类的公共成员，然后再放置私有/受保护的成员。您可以考虑将类中的常用方法放在比晦涩的方法更高的位置。
【讨论】：
如果您热衷于不惜一切代价将这些方法放在不同的源文件中，并且热衷于不惜一切代价将它们放在方法中，您可以通过使用不同的源文件来定义一个 mixin 类并拥有您的 Path 类导入该方法并从该 mixin 中多重继承。所以，从技术上讲，这是相当可行的。
但是，我不推荐这种做法：值得使用“大手笔”（例如多重继承）仅服务于重要目标（例如重用和删除重复），并且以这种方式分离方法是并不是一个特别重要的目标。
如果那些“晦涩难懂的方法”没有发挥作用，那么您就不会实施它们，所以它们一定具有一定的重要性，毕竟；所以我只是在 docstrings 和 cmets 中澄清它们的用途，也许明确提到它们很少需要，然后就这样了。
【讨论】：
我会在名称前加上下划线_，以表明读者不应该打扰它们。
它通常与其他语言中的私有成员相同。
【讨论】：
将它们放在 Path 类中，并用 cmets 或文档字符串记录它们是“晦涩的”。如果你愿意，可以把它们分开。
【讨论】：
哦，等等，我想到了一些东西——我可以在 Path.py 模块中定义它们，其中每个晦涩的方法都将是一个单行方法，它将从当前存在的单独模块中调用函数。通过这种折衷方案，晦涩的方法将在文件末尾包含大约 10 行，而不是文件体积的 50%。
【讨论】：
我建议让它们可以从 Path 类的属性访问，该属性称为“Utilties”。例如：Path.Utilities.RazzleDazzle。这将有助于自动完成工具和一般维护。
【讨论】：