Campbell Ritchie wrote:Why have you made the Enrollment class a singleton? I don't think that is the correct way to write a singleton anyway.
Junilu Lacar wrote:And here's my Student class implementation based on the tests I have written so far:
synchronizeEnrollment(Course) is the callback method I alluded to earlier in this thread. It has package-private (default) scope by design.
Junilu Lacar wrote:Previously,
I wrote:there is at least one logic bug
The design has a number of problems related to breaking the encapsulation of Student and Lesson and misplacing the responsibility of enforcing the following rules:
1. A student can only enroll in a limited number of courses. (Apparently, no more than 2)
2. A course/lesson can only accept a limited number of students as determined by Lesson.getCapacity()
Consider what happens when a student tries to enroll in a course that is already at capacity. I haven't tested it but from what I can tell by just looking at the code, even though a student doesn't get added to a lesson because it is already at full capacity, the lesson will still get added to the student's list of lessons taken as long as they haven't yet enrolled in the maximum number of lessons allowed per student.
Junilu Lacar wrote:
Famous M. Ighodaro wrote:I want to be able to print each course later and the number of students enrolled on it. And also print all the student and the number of course each student enrolled in.
This is the part that most likely will lead to breaking the SRP. Printing a class roster and printing a coarse load are different responsibilities from maintaining enrollment information. If you have methods in a Course class that maintain the roster of students and print the roster of students taking the course then that is a violation of the SRP. Likewise in a Student class if you have methods that maintain information about course load and printing the coarse load. The responsibilities of maintaining the list and printing the list should be separated. Here's why: If you need to change the way the printed list is formatted, ordered, or filtered, it has nothing to do with how the list is maintained. Maintaining the list is therefore a different responsibility from printing the list.
Carey Brown wrote:I believe that would break the principle. You'd end up with Course having a List<Student> and Student having a List<Course>. Then the problem becomes going to two places to add a Student to a Course.
You could have an Enrollment class, for example, with Map<Student,List<Course>> and also Map<Course,List<Student>>. Then you only have to go to the Enrollment object to add a Student to a Course and both maps would be maintained in sync.
Edit: Probably "Set" would be better than List.