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

Question

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

但是，我遇到过许多实例，其中一个或多个类嵌套在另一个类中。在这方面，我的“直觉”是，这样做仅仅是因为方法论极其糟糕——但是，我对现代 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 助手类非常相似，这些类往往不仅仅是“成为助手”，而且随着时间的推移会获得越来越多的状态。

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