Campbell Ritchie wrote:Somebody's sent me pie Thank you, JK
Campbell Ritchie wrote:Depends how the hashCode() and equals() methods work in Student. If a Student object can change its state and therefore its hash code, you will never find it in the Map again.
Jan Kaczmarek wrote:. . . Map<Student, ArrayList<Integer>> . . .
Carey Brown wrote:Does your Repository have, or need to have, persistence behind it, such as files or database?
Carey Brown wrote:Do you really have a database behind this or are you just referring to a data layer that behaves like a database?
Do you really need a Lesson class? The key for the Lesson class is lessonName so why not just use the name as a String instead of enclosing it in another Object?
Here's a simple way of doing this where the Student owns the storage for grades.
This is an educated guess. I don't have access to your original requirements.
Carey Brown wrote:If Lesson is just a key of lessonName, then I'd go with option 1. MUCH simpler.
Carey Brown wrote:Does Lesson have any other attributes other than name?
You could have
The choice isn't exactly clear because it's not a straight forward has-a relationship. The relationship is more like a many-to-many relationship which would mean that you'd end up with a Grades class that has the Student and the Lesson as keys and containing a List<Integer> as its value.
Norm Radder wrote:Where did you get that idea? I think you should Use the tool that solves the problem.