假設你正在建立一個POJO。當你開始一個新的POJO課程時，你會做什麼？
您在設置課程時定義了什麼？
這裏是我的名單
這是大材小用還是音響工程？有什麼遺漏，你會添加？
我假設因爲你提到了一個版本控制方案，我們正在討論持久化類。我會說你有一個很好的列表，但是（取決於你的ORM引擎），我也傾向於確定什麼值（除了自動增量ID），定義任何記錄的「唯一性」。
我只提到這一點，因爲Hibernate與集怪異的行爲，如果你使用的ID中的hashCode，因爲它容易經由過程中途改變。
另外值得注意的是，值得你花些時間看看哪些集合將會是Lazy或者Eager，特別是toString方法（如果你從持久化上下文中分離出來的時候做了toString，可能會導致Lazy-Inits ）。
這一切都取決於對象必須做什麼。例如，如果對象是可變的，它不應該實現equals和hashCode，或者可以比較。如果它永遠不會被序列化，那麼在實現Serializable並且擔心版本控制方面沒有意義。如果該對象是不可變的，則不需要複製構造函數。
我通常用它定義了系統中的一些其他對象希望新的對象做一個接口開始。實現這個接口將會「拉」其他課程。
如果你有很多領域，我會考慮一個建設者 - 如果不變性是非常重要的。
就這個矯枉過正而言，它確實取決於很多用例。如果這是一個用於自己的代碼或幾個密切合作者之間的內部對象，我會說是的，但過早做這些事絕對有點矯枉過正。它使得設計變得更加困難（想想如果添加一個字段，你需要改變多少），而且很可能會創建大量無法使用的代碼。
另一方面，如果您正在尋找一個更大的分佈式項目或公共API，我認爲這符合基本面。至少應該考慮這個清單上的所有內容，即使最終確定該類可以是可變的，例如至少該決定是智能化的。
完整的矯枉過正。申請YAGNI。
設計你的類來完成客戶端代碼所需的東西，也許測試。而已。如果你正在編寫一個圖書館，那麼你當然需要更完整一些。即使如此，作爲一項規則，在您考慮實施之前至少有三個客戶。
請注意，我不會將所有這些都做到所有類。我確實說過一些是可選的。 Comparable是可選的，但在需要將它添加到TreeMaps/TreeSets之前，我已經被咬了，所以如果有邏輯順序，我通常會添加它。 – Fortyrunner 2009-06-15 22:28:17
OP還在評論中提到了他正在考慮在一個大型項目中做這件事的情況，他們在提交/檢查之後事情沒有發生太大變化 – Crowie 2013-11-27 13:22:36