c# - 如果 child 没有 parent 就不能存在，那么 child 的 parent 引用是否合理？

Question

例如，每个人可以有多个 child ，但每个人必须有两个 parent 。然后说(在 C# 中)是否合理

class Human {}

class Father : Human
{
    List<Child> Children {get; set;}
}

class Mother : Human
{
    List<Child> Children {get; set;}
}

class Child : Human
{
    Mother Mother {get; set;} 
    Father Father {get; set;}
}

(另一个例子是一本书的页面——一本书可以有多个页面，但一页必须属于一本书，并且只有一本书，假设我们不引入从书中撕下页面、添加页面等的概念)

我知道在 OOP 中，子对象中的父引用会破坏封装并增加耦合。但是，如果子对象没有父对象没有意义，那么向子对象添加父引用是否正确？

Answer 1

I know that in OOP a parent reference in a child object breaks encapsulation…

不，它没有。如果来自外部的代码应该有理由关心存在这样的关系，那么允许来自外部的代码显示知道。代码不需要知道该关系是否由引用实现，事实上也不必如此。揭示这一点会破坏封装。

…and increases coupling.

啊，确实如此。

所以你需要:

1. 很高兴你不关心这个。
2. 在定义明确的地方处理耦合。

如果你的类是不可变的，一个简单的快乐方式是你不在乎:当你收到一个 Human 它的 Mother, Father 和/或 Children 属性是固定的和只读的，那么耦合也是固定的，不会伤害你。 (如果你有一个引用计数的垃圾收集，它可能会，但这是 .NET，所以你没有)。这不是您可能不关心的唯一方式，但它是一种方式。

否则你需要处理耦合。一种方法是仅让 Mother 和 Father 属性可从外部设置。考虑:

public class Human
{
  private Human _mother;
  private Human _father;
  private HashSet<Human> _children;
  public IEnumerable<Human> Children
  {
    // If paranoid, do a foreach … yield here to stop code casting back to `HashSet`
    // Using ImmutableCollections and calling ToImmutableHashSet() is good too.
    get { return _children; } 
  }
  public Human Mother
  {
    get { return _mother; }
    set
    {
      if(_mother == value) // skip for no-op
        return;
      if(_mother != null)
        _mother._children.Remove(this);
      if(value != null)
        value._children.Add(this);
      _mother = value;
    }
  }
  public Human Father
  {
    get { return _father; }
    set
    {
      if(_father == value)
        return;
      if(_father != null)
        _father._children.Remove(this);
      if(value != null)
        value._children.Add(this);
      _father = value;
    }
  }
}

这种方法通过在 Father 和 Mother 属性中处理耦合来处理耦合，并且仅在这些属性中进行处理。其他方法适用于其他情况，例如根本不存储这些属性的值，但有一种方法可以在调用属性时获取它们。

当然也可以让所有的 Mother、Father 和 Children 属性都是可写的(以及通过访问 获得的集合 child 也是可写的)`并且仍然保持同步，这很难。它是否比必须的更难取决于应用程序。

而不是破坏封装，他们非常依赖它。