是否真的值得为实体类实现 toString()

Question

一贯建议重写（实现）类的 toString() 方法。

• Java API 文档 本身说“建议所有子类重写此方法。”。
• Bloch，在Effective Java中有一项“Always override toString”。只有傻瓜才会反驳布洛赫，对吧？

然而，我开始怀疑这个建议：真的值得为实体类实现 toString() 吗？

---

我将尝试阐述我的推理。

1. 实体对象具有唯一的标识；它永远不会与另一个对象相同，即使这两个实体具有相同的属性值。也就是说，（对于非空 x），以下不变量适用于实体类（根据定义）：

   x.equals(y) == (x == y)

2. toString() 方法返回一个“以文本方式表示”其对象的字符串（用 Java API 的话说）。

3. 良好的表示捕获了对象的本质，因此如果两个表示不同，则它们是不同（不等价）对象的表示，反之，如果两个表示相等，则它们是等价的表示对象。这表明以下不变量可以很好地表示（对于非空 x、y）：

   x.toString().equals(y.toString()) == x.equals(y)

4. 因此对于我们期望的实体 x.toString().equals(y.toString()) == (x == y) 也就是说，每个实体对象都应该有一个唯一的文本表示，由 toString() 返回。某些实体类将具有唯一的名称或数字 ID 字段，因此它们的 toString() 方法可以返回包含该名称或数字 ID 的表示形式。但一般来说，toString() 方法无法访问这样的字段。

5. 如果实体没有唯一字段，toString() 所能做的最好的事情就是包含一个对于不同对象不太可能相同的字段。但这正是 System.identityHashCode()，这是 Object.toString() 提供的。

6. 因此，Object.toString() 对于没有数据成员的实体对象来说是可以的，但对于大多数类，您希望将它们包含在文本表示中，对吧？事实上，您希望包含它们的全部：如果该类型有一个（非空）数据成员x，您会希望包含x。表示中的 toString()。

7. 但这会给保存对其他实体的引用的数据成员带来问题：也就是说，它们是关联。如果 Person 对象具有 Personfather 数据成员，则简单的实现将生成该人的家谱的片段，而不是 Person 本身的片段。如果存在双向关联，则简单的实现将递归直到堆栈溢出，因此可能会跳过包含的数据成员关联？

8. 但是，如果值类型 Marriage 具有 Person doctor 和 Personwife 数据成员呢？这些关联应该由 Marriage.toString() 报告。使所有 toString() 方法正常工作的最简单方法是让 Person.toString() 仅报告身份字段 (Person.name或 Person 的 System.identityhashCode(this))。

9. 看来提供的 toString() 实现对于实体类来说实际上还不错。既然如此，为什么要重写它呢？

---

为了使其具体化，请考虑以下代码：

public final class Person {

   public void marry(Person spouse)
   {
      if (spouse == this) {
         throw new IlegalArgumentException(this + " may not marry self");
      }
      // more...
   }

   // more...
}

在调试由 Person.marry()< 抛出的 IlegalArgumentException 时，覆盖 toString() 会有多大用处？ /代码>?

Answer 1

第三点是这个论点的薄弱环节，事实上我强烈不同意它。 你的不变量是（重新排序的）

x.equals(y) == x.toString().equals(y.toString()); 

我想说的是，

x.equals(y) → x.toString().equals(y.toString()); 

：即逻辑蕴涵。如果 x 和 y 相等，则它们的 toString() 应该相等，但等于 toString() 不一定意味着对象相等（想想 equals()） code>:hashCode() 关系；相等的对象必须具有相同的哈希码，但相同的哈希码不能表示对象相等）。

从根本上讲，toString() 在程序意义上并没有任何“意义”，我认为你正试图向它注入一种意义。 toString() 作为日志记录等工具最有用；你问重写的 toString() 会有多大用处：

throw new IlegalArgumentException(this + " may not marry self");

我会说它非常有用。假设您注意到日志中有很多错误，然后看看：

IllegalArgumentException: com.foo.Person@1234ABCD cannot marry self
IllegalArgumentException: com.foo.Person@2345BCDE cannot marry self
IllegalArgumentException: com.foo.Person@3456CDEF cannot marry self
IllegalArgumentException: com.foo.Person@4567DEFA cannot marry self

您会做什么？你根本不知道发生了什么。如果您看到：

IllegalArgumentException: Person["Fred Smith", id=678] cannot marry self
IllegalArgumentException: Person["Mary Smith", id=679] cannot marry self
IllegalArgumentException: Person["Mustafa Smith", id=680] cannot marry self
IllegalArgumentException: Person["Emily-Anne Smith", id=681] cannot marry self

那么您实际上有机会弄清楚正在发生的事情（“嘿，有人试图让史密斯家族与自己结婚”），这实际上可能有助于调试等。Java 对象 ID 给您不完全没有信息。

Answer 2

看来，提供的 toString() 实现对于实体类来说实际上还不错。既然如此，为什么要重写它呢？

是什么让您认为 toString() 的目标只是拥有一个唯一的字符串？这不是它的目的。它的目的是为您提供有关实例的上下文，而仅仅类名和哈希码并不能为您提供上下文。

编辑

只是想说，我绝不认为您需要在每个对象上重写toString()。无价值的对象（如侦听器或策略的具体实现）不需要重写 toString() ，因为每个实例都与其他实例无法区分，这意味着类名就足够了。

Answer 3

在实体类中拥有 toString() 方法对于调试目的非常有帮助。从实际角度来看，使用 IDE 模板或类似 Project Lombok @ToString 注释大大简化了这一点，并且使其易于快速实现。

Answer 4

我总是出于自己的目的而使用 toString()，而不是因为某些技术要求。当我有一个 Person 类时， toString 方法返回该人的姓名。不多也不少。它并不唯一，但出于调试目的，足以了解人员的含义。特别是在 Web 开发中，当我只需在 JSP 中编写对象名称即可获取人名时，这非常方便，这样我就知道我拥有正确的对象。

如果对象具有一些唯一数据（例如数据库 ID），那么这是 toString() 的完美候选者，因此它可以返回#294: John Doe。但唯一性并不是必需的。

真的...即使布洛赫先生这么说...我认为为实现 toString() 制定任何规则是没有意义的。对于 hashCode() 和 equals() 有意义，但对于 toString() 则不然。

Answer 5

是的，这是值得的。 ToString 有助于为对象的状态提供有形的、可视化的输出。 IMO，这在实体中尤其重要，因为 ORM 或其他第三方库经常打印对象作为其日志记录策略的一部分。

logger.debug("Entity: {}", entity);

显然会隐式调用 toString()。

它一次又一次地帮助我直观地查看实体的状态，以确定它在事务性日志记录中是暂时的还是持久的，以及一般调试。

您愿意看到这个：

DEBUG | pattern: test.entity.MyEntity@12345f

还是这个：

DEBUG | pattern: MyEntity [id = 1234.0, foo=bar, bar=baz]

简而言之，您不会重写 toString 的唯一原因是懒惰。在最近的版本中，Eclipse 甚至有一个 toString 生成器！