Here is the CollegeStudent class code:
And here is the main() method:
I realize that this still needs a lot of cleaning up but I am trying to get something to work here before I go in and make it more efficient, etc.
I'd appreciate any help here. I could also do this whole thing all over again from scratch if anyone can give me some highlevel suggestion as to how I should do so. Thanks.
The assignment was to create a constructor in the CollegeStudent class that would take those three arguments and calculate the projected graduation date. The assignment was to also create 4 fields and corresponding get and set methods for each field. I don't understand why I would want a constructor with arguments, if I am looking for user input...
Suggestions, answers, comments, welcome.
But in the interim, let's have a look at your constructor:
You've got three parameters: first name, last name, and enrollment date. I would expect those parameters to be used to initialize the state of the CollegeStudent, in the form of private variables representing the three values. And yes, the private variables are declared and waiting to be initialized. And yes, you initialize the first name variable and the last name variable. But the value you passed to the constructor, the enrollment date: you ignore that and instead call one of the instance methods. Why did you do that?
You have some problems with the setXXX and getXXX methods. A setXXX method should have void instead of a return type; it should take the new value as a parameter. It should have aCapitalLetter to start the name of the field it is setting: setEnrolmentDate not setenrolmentDate. I think you should go through that method carefully and see what it does. I also think you should consider whether it is worth having a setEnrolmentDate method in the first place. Once somebody has enrolled, are you ever going to want to change that date? Is it good design to have that method at all? If you have some time search for Bean Pattern and see what people think about it. The bean pattern includes setXXX and getXXX methods for all fields. You will find some people are pretty uncomplimentary about it.
Have you been taught about LocalDate? It is pleasing () to see somebody is teaching you to use LocalDate and not those dreadful things Date, Calendar, and GregorianCalendar which should be consigned to history as legacy code.
As far as using void instead of return, I started with that, but I kept getting compile errors stating that ... cannot access a void method...
I will try again.
As far as getter and setter methods. The assignment says I must do this, but I agree with you that it doesn't always make sense.
Can someone clarify why we need the constructor and the setters? My constructor is set up so that all of the fields must be set right away. I'm assuming I have setters in case I need to make specific changes to the object later on.
Here is what happens when I run this:
Please enter your first name:
Please enter your last name:
Please enter the year you enrolled:
Please enter the month you enrolled:
Please enter the day of the month you enrolled:
I am guessing that I am doing something wrong with the LocalDate method...
Also, I'm pretty sure none of your setters will work properly, though you aren't currently using them.
Fortunately my vocabulary neurone has gone to sleep, otherwise I would have had some naughty words to post.
Ray Bell wrote:. . . I was actually told to use GregorianCalendar . . . . The assignment says I must do this . . .
If the assignment says you have to do something, you are stuck with it, whether it is good practice or bad. I suggest you ask your instructor, “Do we really have to use GregorianCalendar? It says in the Java™ Tutorials that it is legacy code.” It's probably better to quote the Java™ Tutorials than to say you read it on the web. If the assignment has been handed out, however, it is too late to change it now.
That's a pleasure
My constructor is set up so that all of the fields must be set right away. I'm assuming I have setters in case I need to make specific changes to the object later on.
Yes, that is the idea of a constructor: set up the object so all its fields have a sensible value. Yes, you might use a setXXX method to change the state of your object later. You don't actually have to use those setXXX methods. But, as I said, if you search for Bean Pattern, you will find varying opinions. Some people will tell you it isn't good programming at all. Ohters will tell you it is all right, but only in very restricted circumstances.
Let's imagine you have a Kettle class with setTemperature and getTemperature methods:-Note both methods take precautions against you setting temperature above boiling point. Also I have “forgotten” about errors caused by incorrectly passing negative arguments. Now you can write this sort of thing:-
myKettle.setTemperature(myKettle.getTemperature() + 10));
I shall leave you to work out which of the two counts as object‑oriented style.
Honey comprises sugar and water. What if the Honey class in this post doesn't have a sugarPercentage field? What if it only has sugarWeight and waterWeight fields? You can implement getSugarPercentage with only a slight arithmetical error like this:-How are you going to implement a setSugarPercentage method? Bees don't set the percentage of sugar in the honey; if they think it is too runny, they buzz to evaporate water, so my implementation (maybe) accords well with real life.
But it doesn't fit the Bean pattern very well.
Like Dave says, this constructor has some useless code. Let's look at enrollmentDate for example. Inside the constructor, plain old enrollmentDate refers to the parameter of that name (because the constructor is the smallest scope where it's declared). And this.enrollmentDate refers to the instance variable of that name (because that's what this means).
So what exactly does "enrollmentDate = this.enrollmentDate;" do? It takes the value of the instance variable and assigns it to the parameter -- which essentially is nothing. Worse than that, it doesn't do what you would want a constructor to do, which would be to do that assignment in the opposite direction.
Enrollment date: Is it supposed to be set when the CollegeStudent object is created? Can it also be changed later?
Graduation date: Is it directly dependent on the enrollment date, or can it be set separately? If it's directly dependent, is it a fixed number of years after enrollment or can the number of years be set later?
If you have some time on your hands, search for Raoul‑Gabriel Urma and how he uses Optionals to avoid nulls.
Thanks to all of your help I think I now have a much better idea of how to work with constructors and getters and setters, so hopefully I can do a better job with the next assignment. I appreciate the way you all respond with patience and respect.
That's a pleasure and I am sure I can speak for the thers who posted here.
Ray Bell wrote:Thanks for all of the educational posts.
That doesn't surprise me, I am afraid.
. . . many students were struggling, especially with the GregorianCalendar . . .
You can add the length of the course to the start date and change it later if the student is ill or something.
He wanted us to calculate the graduation date within the constructor, . . .
That is part of the explanation. If you think there is a better way to do something than what the boss says, you can try to persuade them to change their minds. If you get such a change in an assignment, everybody else will accuse you of cheating. As I said, once an assignment has been given out, it can no more be changed than the law of the Medes and Persians.
I did ask if I could use LocalDate and I was refused. I guess as in real life programming; you gotta do what the boss says whether you like it or not...
What a nice thing to say
Thanks to all . . . . I appreciate the way you all respond with patience and respect.