嵌套类：有用的工具还是违反封装的？

因此，对于是否应使用这些功能，我仍然持保留态度。

我感到它极度违反了封装，但是我发现我可以在某种程度上实现封装，同时在代码中获得更大的灵活性。

以前的Java / Swing项目在某种程度上使用了嵌套类，但是现在我进入了C＃中的其他项目，因此避免使用它们。

您如何看待嵌套类？

好吧，也可以简单地说：嵌套类不违反封装，并且一般而言，语言功能也不违反编程原则。程序员违反了编程原则。

有趣的是，据称嵌套类增加了封装：

增强的封装-考虑两个顶级类A和B，其中B需要访问A的成员，否则将其声明为私有。通过将类B隐藏在类A中，可以将A的成员声明为私有，而B可以访问它们。另外，B本身可以对外界隐藏。

这是有道理的。

通常，B是将SRP应用于A 的结果。然而，B本身有可能违反许多原则，尤其是如果它所做的只是与A的私人成员混在一起的话：D

我认为隐藏的类可能有用。但是，滥用的可能性很大。

我们一直在使用嵌套类。在许多情况下，业务软件/流程具有嵌套的业务对象。我们都已经看到了Order对象的示例，该对象具有OrderItems的嵌套集合。

最重要的是，它使读/写代码更加容易，并且在极少数情况下，您将需要Order类，而无需了解OrderItems。

就我个人而言，我认为应该避免使用它们，因为它们确实以各种（通常是不利的）方式耦合您的设计。

但是，如果您的项目具有设定的作用域并封装了一个类（例如Node类或用于遍历特定类的数据结构的某种对象），那么我看不到这种危害。

实际上，我认为对于某些类型的项目，它会使代码（和推理）更加清晰/易于理解。但是，我认为对于大多数考虑到可扩展性的项目来说，这是一个坏主意，因为很少将它们分开会给您带来麻烦，但是将它们放在一起可能会迫使您将来将它们分离（这是浪费的时间）。

（在C＃中）通常我会避免使用它们，尽管它可以完全取决于类的目的。

我绝不会将它们用于任何类型的域模型类，这对我来说毫无意义。

我曾经使用它们来构造外部类中私有的数据，但是我发现这些几乎总是最终在项目生命周期的后期需要外部使用，因此我通常不再为此而烦恼。

我现在唯一使用它们的原因是奇怪的小编码技巧，其中使用另一个小类使实现特定的类更容易，或者实现实际上只是事件通知模式的接口（内部类将实现接口并通过控制外部类）。