我的问题与这个有关：Python tool that builds a dependency diagram for methods of a class。
在没有找到任何工具后，我自己编写了一个快速 hack：我使用了编译器模块，我已经将源代码解析为一个抽象源代码树，并且我已经遍历它来收集类方法之间的依赖关系。我的脚本为 graphviz 生成了一个输入文件，该文件用于生成一个看起来像 this 的依赖关系图。
此时我被卡住了。我意识到我不知道如何重构该类以使其不那么复杂。我根本不知道我应该瞄准什么。例如，在关系数据库的理论中，有一些简单的规则可用于将数据库变为正常形式。关于良好的类设计（就其方法之间的依赖关系而言）的一些类似理论呢？是否在某个地方涵盖了这个主题，以便我可以研究它？
【问题讨论】：
标签： python language-agnostic oop
我们在设计类时遵循以下原则：
编辑：设计模式有助于让您的代码符合这些原则。我发现先了解原则然后查看模式并了解模式如何使您的代码符合原则非常有帮助。
【讨论】：
在课堂设计方面，通常无法说出“正确”或“错误”。关于这个主题有很多指导方针、模式、推荐等，但归根结底，恕我直言，这与过去项目的经验有关。我的经验是，最好不要太担心，逐步改进你的代码/结构。进行实验，看看一些想法/变化的感觉/外观。当然，向他人学习总是一个好主意。阅读大量代码并分析它，尝试理解:)。
如果您想了解理论，我可以推荐 Craig Larmanns 的“应用 UML 和模式：面向对象分析和设计以及迭代开发简介”Amazon。他涵盖了您问题的几个部分，给出了一些粗略的指导方针，并使用示例应用程序展示了它们。我喜欢这本书。
你能把你的应用上传到某个地方吗？也许在 github 上，也许你可以寻求一些具体的建议。
【讨论】：
Design Patterns 已成为良好类设计的事实标准。通常，每种模式都有其适用的特定用例或场景。如果您可以在代码中识别出这一点，则可以使用该模式来创建更有意义的东西，并且通常具有更少的依赖关系。
重构是您用来完成这些彻底改变的工具。一个好的 IDE 会帮助你重构。
【讨论】：
尝试使每个方法都易于进行单元测试。我发现这总是使我的设计朝着更具可读性/可理解性的方向发展。有许多 OOAD 规则 -- SRP, DRY, etc. 在重构时尽量记住这些规则。
【讨论】：
我推荐 Martin Fowler 的《重构》一书，其中包含大量将糟糕的设计迭代转化为优秀设计的实际示例。
【讨论】：