JPA/Hibernate：サブタイピングvs.戦略「パターン」

Question

以下は、JPA注釈付きタイプの階層で、すべてのデータフィールド（および関連するゲッターとセッター）は、スーパータイプのメンバーと、ビジネスロジックを実装するための抽象的な方法です。データメンバーを追加せずにこれらの抽象的なメソッドを実装するサブタイプは数多くあります。したがって、単一のテーブル継承戦略を使用して、このタイプの階層をバックするためにデータベースに1つのテーブルのみが必要です。

データの内容に基づいて、究極の目標を達成するために実装する必要があるさまざまな動作があるため、私はこのようにしました。

@Entity
@Table
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn
public abstract class SuperEntity {
  // Several fields and getters and setters
  ...
  // Abstract method declarations for business logic
  ...
}

@Entity
@DiscriminatorValue("some value")
public class SomeSubtype extends SuperEntity {
  // Implementations of abstract methods
  ...
}

これは、JPA/Hibernateの識別子列の概念の倒錯ですか？

同僚は、データの構造はサブタイプからサブタイプまで変化しないため、抽象的なメソッドと対応する実装を戦略パターンアプローチのようなものに移動する必要があると主張します。彼の概念は良いですか？

Answer 1

Betterは非常に主観的です。構成と戦略は有効な代替手段のように聞こえます。これにより、ビジネスロジックの実装ごとに別のエンティティをマッピングする必要がないようになります。

JPAとHibernateは別として、私が今まで読んだすべてのOOデザインブックは、行動を共有するための「継承に対する好意的な構成」から始まります。

データオブジェクトを1つ持っていたとしたら、各非婚stertation戦略の間でオブジェクトを共有して、それに基づいて動作できませんか？ JPA/hibernateが少ないことは、とにかく目で簡単です。