.net 公共的嵌套类型

我很好奇在涉及.NET中嵌套类型的特定场景时，什么是好的实践

假设您有一个轮子类，轮子类保存轴承对象。轴承对象仅在车轮内有意义，并且您不希望允许独立创建它，因此将轴承类嵌套在车轮对象内是有意义的。但是，假设您有一个场景，您现在需要读取Wheel类之外的Wheel.bearations属性。这现在需要将嵌套的轴承类公开

在这种情况下，最好的选择是什么？
1-创建嵌套在车轮类中的公共轴承类
2-创建一个独立的轴承类，该类在其构造函数中接受一个车轮对象
3-创建一个轮子名称空间，并在此名称空间内创建一个独立的轴承类。
还有别的吗

更新： 我正在更新更多的细节，以反映到目前为止的一些建议。ClassParent是父类，ClassChild是子类。ClassChild始终是ClassParent的子级，单独存在是没有意义的。问题是ClassChild有几个属性需要公开，而其余的属性都应该只从ClassParent调用。一个例子是ClassChild.Delete函数，它不应该公开，因为它只应该在ClassParent需要执行适当的清理和修改时从ClassParent调用

在审查了这些建议之后，我提出的设计看起来有点不干净，所以我想我应该征求意见。我有：

public class Parent
{
  ChildNested childObj

  public DeleteChild()
  {   
      //expose this method publically
      childObj.DeleteChild()
      //other functionality 
  }

  public Child GetChild()
  {
      //expose Child, not ChildNested publically
      return childObj
  }

   private class ChildNested:Child
   {
         public Child()
         {
              Base.Child()
         }
         public DeleteChild()
         {
              Base.Delete()
         }
   }

public abstract class Child
{
 protected Child()
     {
     }
 protected Delete()
     {
     }
     public PublicPropertyToExpose()
     {
     }    
}

---

这里最好的设计是使用

内部

构造函数创建一个公共

轴承

类，并在

轮子

类中创建它的实例

如果

轴承

类需要访问

车轮

类的私有成员，则可以将

轴承

类

抽象

，然后将其作为

车轮

内部的

私有

嵌套类进行具体实现

一般来说，.

• 使用私有构造函数创建独立的轴承类
• 创建一个工厂类，该类将实例化给定轮子类的轴承类

---

我想独立测试“轴承”，所以我会选择第二个选项

轴承可以独立存在，因为它可能足够有用，可以用于世界其他地方，车轮之外

通过使用轴承聚合控制盘，但控制盘不定义轴承。轴承是有用的，可以用于除车轮以外的其他用途

轴承需要一个公共属性这一事实表明它需要是一个公共类，而不是轮子

还有，当你重新发明轮子时会发生什么（我们都会…）。也许您使用了一种新的“空气轴承”，例如微型涡轮机中存在的轴承，现在您在车轮类中有多种轴承类型，其中一些没有使用

---

我将轴承放在同一名称空间中，但不放在Wheel类中。我很少发现需要内部类。通常，一个匿名类会填补我需要的任何空白。

或者在wheel上有一个返回轴承的方法，比如“CreateWheeting”。+1。我完全同意。嵌套类型很难读取，也很难遵循。当你针对它们编程时，你总是需要指定输出类型，这很烦人。但是如果情况是轴承不可能也不应该没有轮子存在呢？因为在这种情况下，实际上可以创建没有轮子的轴承对象。例如，一个键盘类和一个键类，如果没有键盘，就永远不能有一个键体键。有没有办法创建一个类，该类有两个（或更多）派生自它的公共类，但不是“公开”派生的，除了通过使用私有构造函数使基类为公共之外，然后将派生类嵌套在其中？在设计类层次结构时，我经常发现自己被困在一个角落里，我想成为公共类的东西被困在其他类中。除了给一些比我真正想要的更大的作用域之外，还有什么好办法吗？@super：给基类一个

内部
构造函数，并密封派生类。我想这并不可怕，尽管将作用域放在应该的位置需要将类拆分为自己的程序集，这似乎是一个公平的工作；否则，类的作用域将比它实际应该拥有的更大。嵌套类的作用域是完美的；唯一令人烦恼的是，外部名称最终过于复杂。