動的に構成するオブジェクトを構成する

Question

私は、コースごとに複数のオブジェクトで構成されたコースのレビューテーブルを用意しています。学生は毎月登録しているコースを確認する必要があります。数学、科学、外部キーをレビューテーブルに格納して、コースの各レビューがそれぞれのテーブルに関連付けられるようにします。

注：生徒はたった2つのコース

@Entity 
class Review{ 
//multiple time fields here here 

@OneToOne(cascade=CascadeType.ALL,optional=true) 
@JoinColumn(name="math_review_id") 
Math m; 

@OneToOne(cascade=CascadeType.ALL,optional=true) 
@JoinColumn(name="science_review_id") 
Science s; 

@OneToOne(cascade=CascadeType.ALL,optional=true) 
@JoinColumn(name="history_review_id")   
History h; 

} 

スーパークラス

@MappedSuperclass 
class Course { 
    @Id 
    @GeneratedValue(strategy=GenerationType.IDENTITY) 
    @Column(name="id") 
    int id; 

    @ManyToOne(fetch = FetchType.LAZY, 
     cascade = { CascadeType.DETACH, 
        CascadeType.MERGE, 
        CascadeType.PERSIST, 
        CascadeType.REFRESH }, 
        ) 
    @JoinColumn(name = "student_id") 
    private Student student; 
} 

サブクラス歴史

@Entity 
class History extends Course{ 
//fields specific to history course 
} 

サブクラス数学

に

@Entity 
class Math extends Course{ 
//fields specific to math course 
} 

を登録することができます

Studentクラスは

@Entity 
class Student{ 
//fields name,id,... 
@OneToMany(mappedBy = "student", 
      cascade = CascadeType.ALL, 
      fetch = FetchType.LAZY) 
private List<Review> reviewsList; 
} 

私は、学生がに登録されているもののコースをチェックして、数学、科学、歴史accordingly.Iは私reviews.jspにレビューオブジェクトを渡すと、休止状態を使用して返さ@ModelAttributeを保存して初期化します。初期化されていないオブジェクトは保存されませんが、hibernateは初期化されていなくてもnullエントリを作成します（私はテーブルにマッピングされ、永続クラスの内部にあるためだと思います）。私は、学生が登録されたコースだけで、レビューオブジェクトを動的に構築する方法を手助けする必要があります。私の現在の設計にはフローがあり、より良い設計提案は高く評価されます（私はJavaと休止状態で最小限の経験があります）

Answer 1

提案として私はコースごとにクラスを作成するのに疲れているはずだと思います。数学、科学、または歴史のようなタイプのメンバを持つCourseクラスを持つことは十分ではないでしょうか。たとえそのタイプでもそれ自体がエンティティになる可能性があります：CourseType、あなたのコードには、Math、ScienceまたはHistoryはありません。その代わりに、それらはコードの代わりにデータベースにあります。

Reviewオブジェクトは、Courseとのみ対話します。あなたが別のコースを追加するときに行う必要があるすべての作業についても考えてください。あなたは多くの異なるファイルを更新しなければならず、データベースにテーブルを追加する必要があります。私はあなたがそれをする必要があるとは思わない。

私は、あなたがコースのクラスの間にいくつかの違いがあるかもしれないと思います。そして、これらをすべて1つのクラスに入れて少し厄介かもしれません。しかし、私の経験から見ると、これはコードの量を大幅に減らし、コードなしでさらに多くのコースを追加できるようにするため、通常は価値があります。

編集コースごとに1クラスの決定を再評価することをお勧めしますが、とにかく決定します。このReviewオブジェクトが何であるかは本当に不明です。学生は2つのコースしか登録されていないと言いますので、これらのフィールドのうち2つがヌルであると想像してください。しかし、それはコースごとに1つのクラスを持っているので私を混乱させますが、すべての科目に渡って過度のレビューオブジェクトを持っています。あなたのレビューがあなたのMath内のフィールド、またはScienceコースに依存する場合それ以外の場合は、私は各コ​​ースの見直しクラスを持つことが期待される

class EnrolementReview{ 
    Course courseA; 
    Course courseB; 
} 

を：私は見て期待した

class MathReview { 
    MathCourse course; 
} 

それとも、レビューのための汎用基本クラスを持つ可能性があります。

abstract class CourseReview<C extends Course> { 
    C course; 
} 

そして、学期中に2クラスを見直すためのSemesterReviewクラス：

class SemesterReview{ 
    CourseReview review1; 
    CourseReview review2; 
} 

限りdynamic compositionとして、IMO私はそれが静的に型付けされた言語で、この概念をはるかに理にかなっているとは思いません。ビルダーパターンやケーキパターンなどがあります。いくつかのプログラミング言語はScalaの特質のようにこの領域に素晴らしいものがいくつかありますが、そのメリットは非常に限られています。Javaではできないものは何もありません。デザインパターンと開発者としてあなたに利用可能な方法のすべての多くの順列のために

、私は、それはあなたの設計上の決定の出力の一部を見て少し簡単だと思うような：

• どのように多くの私は書くつもりですか？
• コードを記述せずにコースを追加し、 データベーステーブルを変更することはできますか？
• 他の人が自分のコードを理解できますか？

最終編集 懸念され、多くのヌルフィールドに関しては、あなたはいくつかのオプションがあります。どちらのフィールドにもヌルフィールドがありますか、エンティティとして変数タイプをカプセル化するようなことをしています（例えば、各コースにはString、Integers、Doublesなどのリストがあります）。多くの異なる状況でビット。それは正常に動作しますが、変数名がscienceCategoryなどの整数が必要な場合があるため、実行時にコンパイルされた可能性がある領域をいくつか遅延させます。構造化されたデータがある場合は、扱いにくいこともあります。一般に、そのアプローチは、クライアントがシステムをどのように使用するのかを本当に分からないので、使用するためにクライアントの多くを公開する場合にのみ有効です。

私の個人的な好みは、あなたのクラスの自然な構成に従うことです。変数のファミリを独自のクラスにカプセル化します。どちらか。しかし、これらのクラスが存在するかどうかは非常に明確ですが、Optional<ScienceInformation>か、このオプションが存在するかどうかにかかわらず、booleanを返すメソッドをいくつか用意する必要があります。次に、作成したシステムのオプションで操作を実行できます。オブジェクトで構成されているオブジェクトのようにネストされたオブジェクトを作成しないように注意してください（必ずしも問題はありませんが、通常はそうです）。

本当に私はそれがあなたが選んだ方法が大事だとは思わないが、どれもクラスを書くことがあなたに与える快適な気持ちをあなたに与えることはありません。ちょうどあなたが維持不能な混乱につながることのない方法で、これらのエンティティ（例えばコース）をどのように抽象化するかについて考える必要があります。あなたは明らかにあなたのドメインについての完全な知識を持っていますが、私はあなたがコードを読んでコメントを読まなくてもそれを見つけることができます。それは不正行為である）、その質問に対する答えは何か。