アノテーションを変更するためにJavaでサブクラスを作成するのは悪い習慣と考えられますか？

Question

たとえば、JPAやHibernateのコードを書くときには、ドメインクラスの子孫、例えばAccountを作成したいと思うかもしれません。下位バージョンは、ユーザーに表示されるフォームを表します。フォームには、アカウントにあるフィールドの約半分しかありません。したがって、私がフォームの値を保持するために使用するオブジェクトは、他のフィールドを変更すべきではありません。

継承を使用してアノテーションを変更すると、悪いとみなされますか？そうではないとすれば、それをより効果的に、あるいはより効果的に行うための良い短い手やデザインパターンがありますか？

Answer 1

ここで説明したケース（少なくとも私がそれをどのように理解したか）は、サブクラスを作成するための良い候補ではないと思います。

基本的に、エンティティの一部のフィールド/アソシエーションのみを変更するようにフォームを制限したいのですが、そうですか？私はさらに、フォームの開発者が編集可能なフィールドのみが変更されていると信じていないと仮定しているため、それを制限する必要があります。

この場合、1つの選択肢はDTO pattern（データ転送オブジェクト）を使用することです。フォームデータのDTOを作成し、ユーザーにそのフィールドを入力させます。次に、DTOをサービスに渡します。サービスに応じてエンティティを更新します。この方法で、編集可能なフィールドと更新の実行方法を制御できます。

編集不可能なフィールドのセッターが呼び出されたときに例外をスローするエンティティーのラッパーを作成する方法もあります。しかし、それは実行時の解決策であり、私はここでDTOのアプローチを好むだろう。

編集：

継承が、この場合に問題になるかもしれないいくつかの理由：

• サブクラスは実体を表すものではありません、しかし、あなたはまだ上のサブクラスを表現する必要があると思います
• そのフォームで作成されたエンティティは常にサブクラスを持つため、他の場所では編集できません（データベースを使いこなす場合を除きます）
• エンティティはデータコンテナであり、プレゼンテーションに依存しないでください。したがって、1つのUI用の特殊なエンティティ（サブクラス）を使用すると、モデル/データとビュー/プレゼンテーションレイヤー間の単一責任の原則と抽象が破られます。