-2

以下のクラス間の関係モデルを改善できるかどうかを知りたいです。MongoDB をデータベース層として使用しています。

public class TodoItem {
 private String description;
 private Person person;
}

public class Person {
 private List<TodoItem> items;
}

繰り返しになりますが、私の質問は、一対多や双方向などの関係が関係するクラスの設計に固有のものです。ありがとう。

4

3 に答える 3

3

それは本当にあなたの要件/環境に依存します。

たとえば、双方向の依存関係があります。それらは維持するのが面倒ですが、これを使用するクライアントにとっては良いことです。もっと重要なことは何ですか？多かれ少なかれ同じ頻度で両方の方法をナビゲートする必要がありますか?

完全なオブジェクトを保存します。代わりにプロキシを保存するか、ID とリポジトリを保存する必要があるかもしれません。機能と非機能の両方の要件について知るまで、誰にもわかりません。

実際、要件がない場合、要件を満たすのに役立たない場合はクラスを持つべきではないため、設計は間違っています。

ソフトウェア設計に絶対的な善悪はありません。そのような決定が可能であれば、手動で行う必要はなく、すべての現代言語で言語機能として利用できるようになります. 設計とは、要件を理解し、設計の決定がそれらの要件の達成度に与える影響を理解することです。

したがって、デザインについて学びたい場合は、次のことを試してください。

単純な機能要件を取り上げて、機能以外の要件が変化すると設計がどのように変化するかを考えてみてください。チップ カード上で実行する必要があります。毎秒数千のリクエストを処理する必要があります。書き込みが多く、読み取りが少ない。読み取りが多く、書き込みが少ない。...

于 2012-02-09T21:22:05.717 に答える
1

双方向の関連付けが本当に必要ですか? たとえば、部門は所属する会社を知る必要がありますか?

一方向の関連付けを使用すると、カップリングが少なくなり、Department何も知る必要がありませんCompany(または、変更された場合にCompany変更する必要はありません)。Project、Employee、 ...についても同様です。

これ以上の情報がなければ、私が見るのはそれだけです。

于 2012-02-09T16:04:55.807 に答える
0

簡単な答えは

public class Company {
 private List<Department> departments;
}

public class Department {
    private List<Employee> employees;
    private List<Project> projects;
    private Map<Employee, Project> employeeProject;
}

public class Employee {
   private String name;
}
于 2012-02-09T16:23:54.200 に答える