在 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等于空？或者他们会指向自己？