POJOを設定しているとしましょう。
クラスを設定するときに何を定義しますか？
これが私のリストです
これはやり過ぎですか、それとも健全なエンジニアリングですか？追加するものがありませんか？
自分が何をしたいのかがわかっている場合は、通常、最初にテストを作成してから、クラスを作成して実行します。
あなたがバージョニングスキームについて言及したので、私たちは永続的なクラスについて話していると思います。
そこには素晴らしいリストがあると思いますが、（ORMエンジンによっては）、レコードの「一意性」を定義する値（自動インクリメントID以外）も決定する傾向があります。
hashCodeでIDを使用すると、プロセスの途中で変更される可能性があるため、hibernateはSetsで奇妙な動作をするため、これについてのみ言及します。
また、特にtoStringメソッド（永続コンテキストから切り離されているときにtoStringを実行するとLazy-Initsが発生する可能性があります）の場合、どのコレクションがLazyまたはEagerになるかを確認する価値があることにも注意してください。
それはすべて、オブジェクトが何をしなければならないかに依存します。たとえば、オブジェクトが可変である場合、equalsとhashCodeを実装したり、比較したりすることはできません。シリアル化されない場合は、Serializableを実装してバージョン管理について心配する必要はありません。オブジェクトが不変である場合、コピーコンストラクタは必要ありません。
私は通常、システム内の他のオブジェクトが新しいオブジェクトに実行させたいことを定義するインターフェースから始めます。そのインターフェースを実装すると、クラスの残りの部分が「プル」されて存在します。
フィールドがたくさんある場合は、ビルダーを検討します-不変性がそれほど重要な場合。
このやり過ぎという点では、実際にはユースケースに大きく依存します。これがあなた自身のコードで、または数人の緊密な協力者の間で使用するための内部オブジェクトである場合、私はそう言うでしょう、これを時期尚早に行うことは間違いなくやり過ぎです。これにより、設計の進化が難しくなり（1つのフィールドを追加した場合にどれだけ変更する必要があるかを考えてください）、使用されないコードが大量に作成される可能性があります。
一方、より大規模な分散プロジェクト、またはパブリックAPIを検討している場合、これは基本に当てはまると思います。少なくとも、このリストのすべてを考慮する必要があります。たとえば、クラスが変更可能であることが最終的に決定された場合でも、少なくとも決定はインテリジェントに行われました。
完全なやり過ぎ。YAGNIを適用します。
クライアントコードによって必要とされることを実行するようにクラスを設計し、おそらくテストします。これ以上何もない。ライブラリを作成している場合は、もちろん、もう少し完全である必要があります。それでも、原則として、コミットを検討する前に少なくとも3人のクライアントがいます。