假设您正在设置 POJO。
您在设置课程时定义什么?
这是我的清单
- 使用提供的字段创建对象的构造函数(这样我可以使字段成为最终的,因此是不可变的)
- 等于
- 哈希码
- 实现可比
- 获取方法(如果适用)
- [可选] 可变字段的复制构造函数 - 保证类的不变性
- [可选] 定义访问字段和方法的接口。
- [可选] 实现 Serializable 并实现版本控制方案。
这是矫枉过正还是声音工程?有什么要补充的吗?
如果我知道我想做什么,通常会先编写一个测试,然后编写类以使其运行。
我假设因为您提到了版本控制方案,所以我们正在谈论可持久化的类。
我想说你有一个很好的列表,但是(取决于你的 ORM 引擎),我也倾向于确定哪些值(除了自动增量 ID)来定义任何记录的“唯一性”。
我只提到这一点是因为 hibernate 对 Sets 有奇怪的行为,如果你在 hashCode 中使用 ID,因为它很容易在过程中途改变。
还值得注意的是,值得花时间查看哪些集合将是 Lazy 或 Eager,尤其是对于 toString 方法(如果您在与持久性上下文分离时执行 toString,这可能会导致 Lazy-Inits)。
这一切都取决于对象必须做什么。例如,如果对象是可变的,则不应实现 equals 和 hashCode 或可比较。如果它永远不会被序列化,那么实现 Serializable 并担心版本控制是没有意义的。如果对象是不可变的,则不需要复制构造函数。
我通常从一个接口开始,该接口定义系统中的其他对象希望新对象做什么。实现该接口将“拉动”该类的其余部分。
如果您有很多字段,我会考虑使用构建器-如果不变性那么重要。
就这种矫枉过正而言,它实际上在很大程度上取决于用例。如果这是一个用于您自己的代码或几个密切合作者的内部对象,我会说是的,过早地完成所有这些肯定是矫枉过正的。它使设计的发展变得更加困难(想想如果添加一个字段,您必须更改多少)并且很可能会创建很多不会被使用的代码。
另一方面,如果您正在查看一个更大的分布式项目或公共 API,我认为这触及了基础。至少,应该考虑此列表中的所有内容,即使最终决定类可以是可变的,例如,至少该决定是明智地做出的。
完全矫枉过正。应用 YAGNI。
设计您的类以执行客户端代码对它们的要求,并可能进行测试。而已。如果您正在编写一个库,那么您当然需要更完整一些。尽管如此,作为一项规则,在您考虑提交之前,至少要有三个客户。