在 Java 中使用子对象作为父对象属性是不好的做法吗？

Question

例如，我有一个名为 entity 的类，它看起来像public class Entity {   private User userCreated;   private Date dateCreated;   private User userModified;   private Date dateModified;}然后我有我的 User 类，它实际上是 Entity 的子类public class User extends Entity {    private String username;}我感觉关系中有一个循环，但是对象在我的系统中以这种方式相关，因为我所有的数据都是一个实体，我所有的实体都是由用户创建的，包括我的用户，所以我的用户是一个实体。我已经测试了代码并且它有效，我的问题是，这种设计是否糟糕？如果它不好，有没有更好的方法来实现它？

Answer 1

一般来说，这没有什么不好。如果基类包含需要了解其所有子类的逻辑（例如，为了决定在某些方法调用中返回哪个实例），这只是一种不好的做法，因为这可能会破坏基类（或强制它更新）任何时候引入新的子类。

另一方面，JDK 本身包含引用其子类的类的示例。

例如（虽然这可能有点作弊），Object该类包含对Stringand 的引用Class，它们是它的子类。

如果你的阶级关系需要它，它没有错。

Answer 2

一般来说，你不想要双向依赖，也不希望基类知道它的子类，但只是相反，因为它们都可能在类之间创建强耦合，即任何一方的变化都可能有双方的后果。

但这并不意味着您不想使用这种耦合。

有时这种耦合是不可取的，但有时是可取的，在这里它似乎是一种可取的耦合：父级和子级在语义上非常耦合，因此以后您想要隔离用户或实体的可能性很小他们之间更加独立。

所以你接受甚至希望这种耦合避免没有价值的重复/复杂性。

请注意，您可以通过引入一个接口来定义实体来解耦事物，但是很多代码无法获得一个伟大的东西：

public interface EntityAble {

   User getUserCreated();

   Date getDateCreated();

   User getUuserModified();

   Date getDateModified();

  // setters

}

定义实体，例如：

public class Entity implements EntityAble {

   private User userCreated;

   private Date dateCreated;

   private User userModified;

   private Date dateModified;

   // override getters/setters

}

和用户为：

public class User implements EntityAble {

   private String username;      

   private User userCreated;

   private Date dateCreated;

   private User userModified;

   private Date dateModified;

   // override getters/setters  

}

现在 Entity 由 User 字段组成，这些字段不是 Entity 而是大量重复/ LOC 不一定会有所收获。

在某些用例中，这种设计可能有意义，但对于您的实际需求来说，这听起来是一种开销。

Answer 3

在我看来，它本身并没有什么坏处。

这实际上只是“对象可以包含自己吗？”这个问题的略微修改版本。两种情况的答案都是一样的——是的，没关系。

例如，链表中的节点将包含对下一个和上一个节点的引用，例如：

class Node

{

    private Node next;

    private Node previous;

}

这个设计没有什么不好。

在你的情况，User 是一种Entity，只是更专业。上面例子的类比可能是Nodeand BranchedNode。

但是，您可能要考虑的一件事是，如果用户要求用户创建它们，那么哪个用户将创建第一个用户？有点鸡和蛋的情况。也许第一个用户将拥有userCreated和userModified等于空？或者他们会指向自己？