Famous M. Ighodaro

Greenhorn
+ Follow
since Mar 14, 2021
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
1
Given in last 30 days
1
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Famous M. Ighodaro

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.


The reason of the Singleton is that the enrollment class is holding the list of enrolled students and lessons. To print out the list of enrolled students and lessons later from another class will possible by calling just one instance of the enrollment class.
I choose this way of writting Singleton because the assignment is not a muiltithreaded application.
1 week ago

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.


I like how you simplified your code. My concern is that, the student class is maintaining a list of enrolled lessons and also updating the lesson object by adding a student to the new course. Won't this be breaking single responsibility principle or I am getting the idea of single responsibility principle all wrong? I am still learning, so explanation if what I am getting wrong will be appreciated.
1 week ago

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.


Thanks for the feedback and thorough analysis of my code above line by line. I found out this bug a few days back and this is how I handled it. Please I any critique is always welcome. I added a removeStudent method to handle it.



1 week ago

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.


Hello, that was the initial idea, I mentioned it on the comment above because I want it to be taking into consideration when any one is answering my question. The SRP I was concerned about is the student and the lesson class maintaining the enrolled lessons and enrolled students respectively.
3 weeks ago

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.


Thanks for your answer, I took your suggestion and this is how the Enrollment class look like now. I am not sure yet of how the enroll method should look like, but this is what I can put into work now.
3 weeks ago
I am working on an assignment project, I have a student class which has a variable such as name and address. Also there is a Course class which has variable such as couseName, teacher, date, startTime and endTime. Will I be breaking the single responsibility if I add an ArraylList instance variable to the Course class to maintain the list of student that enrolled on the course? This question  arises after reading the single responsibility principle. 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.
3 weeks ago