假设您正在设置POJO。
您在设置课程时定义了什么？
这是我的清单
这是过度杀伤还是声音工程？你想添加什么遗漏？
答案 0 :(得分：6)
如果我知道自己想做什么，通常先写一个测试，然后编写课程让它运行。
答案 1 :(得分：2)
我假设因为你提到了一个版本控制方案，我们讨论的是可持续的类。
我会说你有一个很好的列表，但是（取决于你的ORM引擎），我也倾向于确定什么值（除了自动增量ID），定义任何记录的'唯一性'。
我只提到这一点，因为如果在hashCode中使用ID，hibernate对于Sets有奇怪的行为，因为它可能会在整个过程中途发生变化。
另外值得注意的是，值得花时间查看哪些集合将是Lazy或Eager，尤其是对于toString方法（如果在从持久化上下文中分离时执行toString，则可能导致Lazy-Inits）
答案 2 :(得分：1)
这完全取决于对象必须做什么。例如，如果对象是可变的，则它不应该实现equals和hashCode或具有可比性。如果它永远不会被序列化，那么实现Serializable并担心版本控制是没有意义的。如果对象是不可变的，则不需要复制构造函数。
我通常从一个接口开始，该接口定义系统中某些其他对象希望新对象执行的操作。实现该接口将“拉动”该类的其余部分。
答案 3 :(得分：1)
如果你有很多领域，我会考虑一个建设者 - 如果不可变性那么重要。
就这种矫枉过正而言，它在很大程度上取决于用例。如果这是一个内部对象，可以在你自己的代码中使用，或者在一些密切的合作者中使用，我会说是的，过早地完成所有这些操作绝对是过分的。它使设计变得更难（想想如果你添加一个字段你必须改变多少），并且很可能创建大量不会被使用的代码。
另一方面，如果您正在查看更大的分布式项目或公共API，我认为这会影响基础。至少应该考虑这个列表中的所有内容，即使最终决定该类可以是可变的，例如，至少决定是智能的。
答案 4 :(得分：0)
完全矫枉过正。申请YAGNI。
设计您的类以通过客户端代码执行它们所需的操作，并且可能进行测试。而已。如果您正在编写一个库，那么当然您需要更完整一些。即便如此，通常情况下，在考虑提交之前至少要有三个客户。