Notes on Assignment 2: A StudentInfo Class

This is a short set of notes on assignment 2. I will go over other details in class.

• Sample Code Files
• Expectations
• Quick Notes

Sample Code Files

• StudentInfo.java
• Address.java
• Name.java
• FacultyInfo.java

Expectations

What was I looking for in your assignments? An essential part of the assignment was a demonstration that you could think about the fields that one would need for a student. While there are probably hundreds of possible fields, I did want to see, at minimum, name, gpa, id number, and one other thing. If you chose a particularly nice group of fields, I gave you a little bit of extra credit.

I also wanted to see that you could write working Java code. I'm pretty sure that all of you were able to write code that compiled and did something useful.

I particularly looked that you met the basic requirements of the assignment. In addition to the fields, I expected a constructor, some getXXX methods, some setXXX methods, a toString method, and one other interesting method. (Yes, I know that there's not much interesting to do with basic student information, but I expect that as Grinnell students you can be pretty creative.) I also expected that you tested most (if not all) of your methods.

Quick Notes

Some of my criticisms may currently seem pointless (e.g., that I expect you to write a comment for every field and method, even t he ones that have only one line). However, I find that if you make it a point to always do these things, you develop good habits.

• Use Javadoc-style comments (/** ... */) when documenting fields, methods, and constructors. And document every field, method, and constructor.
• Don't forget to comment your right braces.
• When you document a field describe the valid values. (You can also do this in the setXXX methods.)
• Java has capitalization customs. Only class names should begin with an uppercase letter.
• Please choose good variable names. m and fn have little meaning out of context.
• It's pointless to have one-field classes.
• As you'll see from my example, it's always nice to have a toString method in your classes.
• Your utility classes should (almost) never interact directly with the user. An interface class is responsible for the interaction.