1

假设您正在设置 POJO。

您在设置课程时定义什么？

这是我的清单

  • 使用提供的字段创建对象的构造函数（这样我可以使字段成为最终的，因此是不可变的）
  • 等于
  • 哈希码
  • 实现可比
  • 获取方法（如果适用）
  • [可选] 可变字段的复制构造函数 - 保证类的不变性
  • [可选] 定义访问字段和方法的接口。
  • [可选] 实现 Serializable 并实现版本控制方案。

这是矫枉过正还是声音工程？有什么要补充的吗？

4

5 回答 5

6

如果我知道我想做什么，通常会先编写一个测试，然后编写类以使其运行。

于 2009-06-15T22:23:31.777 回答
2

我假设因为您提到了版本控制方案，所以我们正在谈论可持久化的类。

我想说你有一个很好的列表，但是（取决于你的 ORM 引擎），我也倾向于确定哪些值（除了自动增量 ID）来定义任何记录的“唯一性”。

我只提到这一点是因为 hibernate 对 Sets 有奇怪的行为，如果你在 hashCode 中使用 ID，因为它很容易在过程中途改变。

还值得注意的是，值得花时间查看哪些集合将是 Lazy 或 Eager，尤其是对于 toString 方法（如果您在与持久性上下文分离时执行 toString，这可能会导致 Lazy-Inits）。

于 2009-06-15T22:24:43.300 回答
1

这一切都取决于对象必须做什么。例如，如果对象是可变的，则不应实现 equals 和 hashCode 或可比较。如果它永远不会被序列化，那么实现 Serializable 并担心版本控制是没有意义的。如果对象是不可变的，则不需要复制构造函数。

我通常从一个接口开始，该接口定义系统中的其他对象希望新对象做什么。实现该接口将“拉动”该类的其余部分。

于 2009-06-15T22:22:41.060 回答
1

如果您有很多字段，我会考虑使用构建器-如果不变性那么重要。

就这种矫枉过正而言，它实际上在很大程度上取决于用例。如果这是一个用于您自己的代码或几个密切合作者的内部对象，我会说是的，过早地完成所有这些肯定是矫枉过正的。它使设计的发展变得更加困难（想想如果添加一个字段，您必须更改多少）并且很可能会创建很多不会被使用的代码。

另一方面，如果您正在查看一个更大的分布式项目或公共 API，我认为这触及了基础。至少，应该考虑此列表中的所有内容，即使最终决定类可以是可变的，例如，至少该决定是明智地做出的。

于 2009-06-15T22:26:01.737 回答
0

完全矫枉过正。应用 YAGNI。

设计您的类以执行客户端代码对它们的要求，并可能进行测试。而已。如果您正在编写一个库，那么您当然需要更完整一些。尽管如此，作为一项规则，在您考虑提交之前，至少要有三个客户。

于 2009-06-16T00:19:15.803 回答