静态内部类是一个好的想法还是不良设计？

Question

我发现我有几个地方使用了公共静态内部类，这些类设计为扩展“helper”类可以使我的代码更加类型安全、易读。例如，假设我有一个“SearchCriteria”类。对于我搜索的不同内容（搜索词和一组搜索词类型、日期范围等），有很多共同点。通过在静态内部类中进行扩展，我将扩展和可搜索类与特定差异紧密耦合。这在理论上看起来像是一个坏主意（紧耦合不好！），但扩展是针对这个可搜索类的（一个类，一个目的）。

我的问题是，在您的经验中，使用静态内部类（或您所用语言的等效物）是否使您的代码更易读/可维护，还是最终导致了问题？

此外，我不确定这是否是社区维基材料。

- Drew

---

这是一个事实性问题吗？是否有正确答案？如果没有，那么这就是一个讨论话题，最好作为社区维基完成。 - S.Lott

你在谈论哪种编程语言？大多数面向对象的编程语言都没有静态内部类这个概念。 - anon

S.Lott：好的。那就改成社区Wiki。 Neil Butterworth：我想措辞更好的选择应该是嵌套类，而不是静态内部类？这最初是Java。 - Drew

好吧，不少语言也没有嵌套类 - 比如Smalltalk。 - anon

尼尔：好的。然而，我最广泛使用的两种面向对象语言，Java和C++，都有某种形式的嵌套类。因此，我认为这是一个更普遍的问题，而不仅仅是针对Java的。我应该如何更好地标记/表述这个问题？ - Drew

尽管这个问题不仅限于Java，但参考Java教程可能会有所帮助。此外，在Java中，这里描述的是“静态嵌套类”，而“内部类”指的是非静态嵌套类。这个SO问题解释了它们之间的区别。 - amaidment

Answer 1

我觉得这个做法很合理。将它作为内部类，既容易找到，当可搜索类发生变化时也是一个明显的审查对象。

只有在你将不该放在一起的东西耦合在一起时，紧密耦合才是坏的。对于紧密协作的类，例如在您的情况下，其中一个类存在以支持另一个类，那么它被称为“内聚”，这是一件好事情。

- Michael Borgwardt

Answer 2

使用内部类的唯一注意事项是确保您不会在各个地方重复自己 - 也就是说 - 确保在定义内部类时，您不需要在任何其他地方使用该功能，并且该功能必须与外部类耦合。 您不希望最终拥有一堆实现完全相同的setOrderyByNameDesc()方法的内部类。

- rojoca

Answer 3

请注意，类不是重用的单位。因此，类之间的一些耦合是正常和预期的。重用的单位通常是一组相关的类。

在Python中，我们有各种结构。

1. 包。它们包含模块。这些本质上是带有一些Python机制的目录。 2. 模块。它们包含类（和函数）。这些是文件；可以包含任意数量的密切相关的类。通常，在这个级别处理“内部类”业务。 3. 类。它们可以包含内部类定义以及方法函数。有时（并不经常）实际上会使用内部类。这很少见，因为类之间的模块级耦合通常非常清晰。

- S.Lott

Answer 4

“松耦合”的重点在于保持两个类的分离，这样如果您的“SearchCriteria”类中有代码更改，则其他类不需要进行任何更改。我认为，您所谈论的静态内部类可能会使维护代码成为一场噩梦。SearchCriteria中的一个更改可能会让您搜索所有静态类，以找出由于更新而现在已经损坏的哪些类。就个人而言，除非确实有必要，否则我会远离任何此类内部类。

- beyerss

---

这有什么不好呢？比起搜索可能因更改而被破坏的许多顶级子类，这又有何不妥呢？根本没有。 - Michael Borgwardt