静态内部类是个好主意还是糟糕的设计？答案

【问题标题】：Are static inner classes a good idea or poor design?静态内部类是个好主意还是糟糕的设计？
【发布时间】：2010-10-15 01:23:47
【问题描述】：

我发现我有几个地方设计了公共静态内部类来扩展“帮助”类，这使我的代码更加类型安全，并且在我看来，可读性更高。例如，假设我有一个“SearchCriteria”类。我搜索的不同事物有很多共性（一个搜索词，然后是一组搜索词类型、日期范围等）。通过在静态内部类中扩展它，我将扩展和可搜索类有具体区别。这似乎在理论上是一个坏主意（紧耦合坏！），但扩展是特定于这个可搜索的类（一个类，一个目的）。

我的问题是，根据您的经验，使用静态内部类（或任何您的语言等价物）是否使您的代码更具可读性/可维护性，或者这是否最终让您陷入 EOF？

另外，我不确定这是否是社区 wiki 资料。

【问题讨论】：

这是一个事实问题吗？能有正确答案吗？如果不是，这是一个讨论主题，最好作为社区 wiki。
您说的是哪种语言？大多数OO语言没有静态内部类这样的概念。
S.Lott：很公平。社区维基化然后。 Neil Butterworth：我想更好的措辞选择是嵌套类而不是静态内部？这原本是 Java。
好吧，也有不少人没有嵌套类——Smalltalk for one
尼尔：很公平。然而，我最广泛使用的两种 OO 语言，Java 和 C++，都有不同种类的嵌套类。所以我认为这是一个比 Java 更普遍的问题。我应该如何更好地标记/措辞这个问题？

标签： class oop inheritance inner-classes nested-class

【解决方案1】：

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

【讨论】：

这比搜索大量可能被更改破坏的顶级子类更糟糕吗？一点也不。

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

对我来说听起来很合理。通过将其设置为内部类，您可以在可搜索的类发生变化时轻松找到它并成为明显的候选审查对象。

只有当你把并不真正属于在一起的东西仅仅因为其中一个碰巧调用另一个而将它们耦合在一起时，紧耦合才是不好的。对于密切合作的课程，例如当像你的情况一样，其中一个存在以支持另一个时，它被称为“凝聚力”，这是一件好事。

【讨论】：

【解决方案4】：

使用内部类的唯一警告是确保您不会在所有地方重复自己 - 就像在 - 确保在定义内部类时，您不需要在其他任何地方使用该功能，并且，该功能必须与外部类耦合。您不想最终得到一大堆内部类，它们都实现了完全相同的setOrderyByNameDesc() 方法。

【讨论】：