Seminar 2. Your first classes¶
By the end of this session you have three working Java classes from the design you made last week, and you can predict what happens when two variables refer to the same object.
No validation today. Your constructors will accept anything you hand them, including nonsense, and that is deliberate. Next week is about making them refuse. Write the classes first, feel where the holes are, then close them.
Warm-up. Classroom¶
Twenty minutes. Build Classroom from the specification. It is the simplest of the five, and it exercises everything you will need for the next hour.
Four fields, one constructor, getters, three behaviour methods, toString.
Two things to get right, because you will repeat them fifteen times today:
roomNumber and building have getters and no setters. A room does not move to another building. hasProjector has a setter, because equipment does change.
location() returns text, it does not print it. Same for toString. Nothing in this class calls System.out.println.
When it compiles, make two classrooms in a UniversityApp class with a main, print both, and call canAccommodate with a number that fits and one that does not.
If you are still fighting Eclipse at the twenty minute mark, stop and fix that first. Go back to the setup pages.
Main task. Student, Professor, Course¶
Sixty minutes. These three are the system, and you extend them for the rest of the module.
Work through the specification one class at a time. Finish one completely before starting the next, because three half-written classes compile into nothing useful and you will not know which one is wrong.
For each class:
- Fields, all
private. - One constructor that takes everything the object needs. No empty constructor.
- Getters. Setters only where the specification says the value can change.
- The behaviour methods. These are the interesting part.
toString(), with@Overrideabove it.
Where people lose time¶
The behaviour methods are the point, not the getters. academicStanding() and academicTitle() are where a class stops being a box of data. If you run short, write those before you write the last few getters.
this in the constructor. Leave it out and name = name assigns the parameter to itself. The compiler says nothing and your object prints a blank name.
Getter-only fields. studentId, employeeId and courseCode have no setters. If your fingers generated one out of habit, delete it.
One thing at a time. academicStanding() returns a String. It does not print, does not update the GPA, and does not check anything else.
Do not let Eclipse generate everything
Right-click, Source, Generate Getters and Setters is fast and it will produce a setter for every field, including the ones that must never change.
Use it if you like, then read every method it wrote and delete the ones that should not exist. Deleting them is the design work. The generator does the typing and you do the thinking.
Check it works¶
In UniversityApp.main, create two of each, print them all, and call every behaviour method at least once.
Student ada = new Student("S-1001", "Ada Lovelace", 3.9, 2024);
System.out.println(ada);
System.out.println(ada.academicStanding());
Expected shape, not exact wording: one readable line per object, and standings and titles that change when you change the numbers.
Try a student with a GPA of 1.2 and one with 3.5, and check the standing differs. If both say the same thing, your comparison chain is in the wrong order.
Drill. Two names, one object¶
Twenty minutes, and do not skip it because you are behind. This catches a misconception that otherwise surfaces in week eleven, on a deadline.
Write each block, predict the output on paper first, then run it.
One
Student a = new Student("S-1001", "Ada Lovelace", 3.9, 2024);
Student b = a;
b.setName("Ada L.");
System.out.println(a.getName());
Two
Student x = new Student("S-1001", "Ada Lovelace", 3.9, 2024);
Student y = new Student("S-1001", "Ada Lovelace", 3.9, 2024);
System.out.println(x == y);
System.out.println(x.getStudentId() == y.getStudentId());
System.out.println(x.getStudentId().equals(y.getStudentId()));
Three
Four
public static void promote(Student student) {
student.updateGpa(4.0);
}
public static void replace(Student student) {
student = new Student("S-9999", "Nobody", 0.0, 2024);
}
Call both with the same student and print the GPA and name after each. One of them changes something and one does not.
For every prediction you got wrong, draw the boxes and arrows on paper until the picture explains the output. Check your drawing against the diagram on What a variable really holds.
Block two, line two is the one that catches almost everybody. Note down your answer and why.
Commit¶
Ten minutes.
cd C:\dev\java-oop-yourname
git add .
git commit -m "Week 2: Student, Professor, Course and Classroom"
git push
Check on GitHub that the .java files are there and the bin folder is not. If bin appears, your .gitignore is missing or in the wrong folder. Fix it now, because by week four that folder is noise on every commit.
Before you leave¶
- Four classes compile:
Classroom,Student,Professor,Course - Every field is
private - No class contains
System.out.println - No setters on
studentId,employeeId,courseCode,roomNumberorbuilding -
UniversityAppcreates objects and prints them - All four drill blocks run, with your predictions written down
- Pushed, and
binis not in the repository
Going further¶
Write Department. Three fields, and no relationships yet. Ten minutes.
Break your own constructor. Create a student with a GPA of 9.5, a negative year of experience, and a course with 200 credits. All of them work right now. Write down what each one lets through. That list is your task list for next week, written by you.
Two constructors, honestly. The specification says one constructor. Find a case where a second one would genuinely earn its place, not just save typing. Bring it to the lecture.