07-04-2011, 05:12 PM
This doesn't sound like the ideal example for teaching OOP. The suggested subclasses are probably not what you'd make if it were an actual application (you would, for example, have just one Appointment that has some Pattern indicating how many times that appointment is going to occur. Then also possibly some 'dummy' appointments that are saved in the calendar by day, week and/or month, such that you don't have to go through the full list of appointments to get all appointments for a given day/week/month).
But, even given the somewhat shabby example, there's still some 'OOP to apply'.
First, you may want to consider how you want to solve the problem;
Given a date, list all Appointments that occur on that date.
An/the OO-way would be to ask each of the Appointments if they occur on that date, and print something if that is the case (you could even let the appointments print that, but then the method would be useless for any other purpose you may think of later). Thus, the Appointment superclass should have a method that checks if it occurs on a given date. Each of the subclasses should implement that method.
When you start implementing the subclasses, you may notice there's some data they all have (or should have) in common; a (start) date. (if the recurring appointments also go infinitely far back in time, any date will do)
Any time every subclass of a class has the same data, you may want to think about moving that data to the superclass. Sometimes, especially when the project is only just starting, it may be warranted to keep the data in the subclasses. However whenever you know that the data will be part of every subclass, it's a rare case when the data should not go to the parent class.
Regarding the array of appointments, I'd say you would put them wherever your program enters. However another possibility would be to store the array as a static field in the Appointment class.
On one hand this means it's (relatively) nice and orderly, however it also means that you cannot have multiple sets of appointments at the same time.
But, even given the somewhat shabby example, there's still some 'OOP to apply'.
First, you may want to consider how you want to solve the problem;
Given a date, list all Appointments that occur on that date.
An/the OO-way would be to ask each of the Appointments if they occur on that date, and print something if that is the case (you could even let the appointments print that, but then the method would be useless for any other purpose you may think of later). Thus, the Appointment superclass should have a method that checks if it occurs on a given date. Each of the subclasses should implement that method.
When you start implementing the subclasses, you may notice there's some data they all have (or should have) in common; a (start) date. (if the recurring appointments also go infinitely far back in time, any date will do)
Any time every subclass of a class has the same data, you may want to think about moving that data to the superclass. Sometimes, especially when the project is only just starting, it may be warranted to keep the data in the subclasses. However whenever you know that the data will be part of every subclass, it's a rare case when the data should not go to the parent class.
Regarding the array of appointments, I'd say you would put them wherever your program enters. However another possibility would be to store the array as a static field in the Appointment class.
On one hand this means it's (relatively) nice and orderly, however it also means that you cannot have multiple sets of appointments at the same time.