我发现我有几个地方设计了扩展“帮助器”类的公共静态内部类，这使我的代码更加安全，并且在我看来，可读性更高。例如，假设我有一个“SearchCriteria”类。我搜索的不同事物有很多共同点（一个搜索词，然后是一组搜索词类型、日期范围等）。通过在静态内部类中扩展它，我将扩展和可搜索紧密耦合类有具体区别。这在理论上似乎是一个坏主意（紧耦合坏！），但扩展是特定于这个可搜索的类（一个类，一个目的）。
我的问题是，根据你的经验，使用静态内部类（或任何你的语言等价物）是否使你的代码更具可读性/可维护性，或者这最终会在 EOF 中咬你？
另外，我不确定这是否是社区 wiki 材料。
对我来说听起来很合理。通过使它成为一个内部类，当可搜索类发生变化时，您可以轻松找到它并成为审查的明显候选者。
只有当您将并不真正属于在一起的事物耦合在一起时，紧密耦合才是不好的，因为它们中的一个碰巧调用了另一个。对于密切协作的类，例如，在您的情况下，其中一个存在以支持另一个，则称为“内聚”，这是一件好事。
请注意，类不是重用单元。因此，类之间的一些耦合是正常的和预期的。重用单元通常是相关类的集合。
在 Python 中，我们有多种结构。
包裹。它们包含模块。这些本质上是包含一些 Python 机制的目录。
模块。它们包含类（和函数）。这些是文件；并且可以包含任意数量的密切相关的类。通常，“内部阶层”业务是在这个级别处理的。
上课。这些可以包含内部类定义以及方法函数。有时（不经常）实际上可能会使用内部类。这很少见，因为类之间的模块级耦合通常非常清楚。
使用内部类的唯一警告是确保你不会在所有地方重复自己 - 就像 - 确保当你定义一个内部类时，你不需要在其他任何地方使用该功能，并且，该功能必须与外部类耦合。您不想最终得到一大堆实现完全相同setOrderyByNameDesc()方法的内部类。
“松散耦合”的重点是保持两个类分开，这样如果“SearchCriteria”类中的代码发生更改，其他类中的任何内容都不必更改。我认为您正在谈论的静态内部类可能会使维护代码成为一场噩梦。SearchCriteria 中的一项更改可能会让您搜索所有静态类，以找出哪些因更新而损坏。就个人而言，除非出于某种原因确实需要它，否则我会远离任何此类内部类。