c# - 在 C# 和 C++ 中使用嵌套类 - 为什么以及何时？

Question

在我 self 引导的努力中，将我的编程技能和习惯带入 21 世纪(从 Pascal 和 Fortran 迁移到 C# 和 C++)，我一直在研究大量可用的源代码。据我所知，类是独特的“独立”实体(很像它们的函数祖先)。

但是，我遇到过许多实例，其中一个或多个类嵌套在另一个类中。在这方面，我的“直觉”是，这样做只是由于方法论极其糟糕 - 然而，我对现代 OOP 方法论还不够熟悉，无法真正做出这样的决定。

因此，出现以下重叠问题:

将一个类嵌套在另一个类中是否有合理的理由？如果是这样，那么与每个类完全独立相比，这样做的理由是什么？

(注意:我见过的示例都是使用 C#，但似乎这方面同样适用于 C++。)

Answer 1

嗯，这可能需要一个非常有启发性的答案，因此许多人会不同意我的答案。我是那些认为没有真正需要嵌套类的人之一，并且我倾向于同意您的说法:

My 'gut instinct' in this regard is that doing so is simply due to extremely poor methodology

人们认为需要设计嵌套类的情况是功能与外部类中设计的行为紧密耦合。例如。事件处理可以设计在内部类中，或者 Threading行为可以找到进入内部类的方式。

我宁愿重构“外部”类的特定行为，这样我最终会得到两个较小的类，它们都有明确的职责。

对我来说，设计内部类的主要缺点是它们往往会使功能变得困惑，而这些功能很难与TDD这样的主体一起使用。 (测试驱动开发)。

如果您不依赖于测试驱动原则，我认为这不会对您造成太大伤害。 (就像很多事情一样)这是一个品味问题，而不是对错问题。我了解到这个话题可能会导致漫长而令人疲惫的讨论。与是否应该使用 static 非常相似帮助者类的作用往往不仅仅是“成为一个帮助者”，而且随着时间的推移，它们的状态会变得越来越多。

如果您遇到现实生活中的例子，讨论会变得更加具体。在那之前，这将主要是人们的“直觉”。