More Class Hierarchies
Reprising the Mid/Prof/Person example from last class: a design diagram
What we saw last class was that a non-trivial object oriented program usually involves class hierarchies. Designing a program then involves deciding what classes you have, what the hierarchy is (what's derived from what) and — as always — what the interfaces (i.e. the public methods) of each of these classes are. A design then, can be represented nicely as a diagram like the one below, which depicts the design we ended up with at the end of last class.
The blank box in the middle is for adding information on private fields, which is information you also might want to consider before and you start banging out code ... and reconsider as you continue to bang out code!
Reprising the Mid/Prof/Person example from last class: abstract classes and methods
One issue that came up during last class was that the base class Person did
not naturally have a "title()" method. We ended up including it because the "toString()"
method, which did naturally belong in class Person, called "title()", and that forced us
to put some kind of "title()" function in there. The important point is this: we have no
plan to ever have anyone create an instance of class Person; Mid and Prof, yes, but not Person.
We have no intention of anyone ever calling the Person version of the method "title()". There's
actually a very nice way of expressing this in OOP: we make "title()" a abstract method,
and Person an abstract class.
An abstract method is a method that has no body, just a semi-colon. So we would declare "title()" like this:
public abstract String title();It's up to derived classes to provide actual implementations of the method. A class that has one or more abstract methods must itself be declared "abstract". The abstract modifier indicates that the class cannot be instantiated — if it were, we'd have an object on which the "title()" method might be called, but for which no title() body exists. So, an
abstract class cannot be instantiated. Moreover, no class
that extends an abstract class can be instantiated unless it provides defintions for all
the abstract methods in the base class. In our Person/Mid/Prof example we are quite happy
with these restrictions, since we never had any intentions of instantiating class Person,
and Mid and Prof both provide their own definitions of title().
Person.java
import java.util.*;
public abstract class Person {
private String first, last, uname;
public Person(String f,
String l,
String u) {
first = f;
last = l;
uname = u;
}
public boolean before(Person m) {
if (!last.equals(m.last)) {
return last.compareTo(m.last) < 0;
}
if (!first.equals(m.first)) {
return first.compareTo(m.first) < 0;
}
return uname.compareTo(m.uname) < 0;
}
public String email() {
return uname + "@usna.edu";
}
public String fullName() {
return title() + " " + first + " " + last;
}
public String toString() {
return fullName();
}
public abstract String title();
}
A Design Exercise
The main part of today's lesson is an in-class group Object Oriented Design exercise. We will describe what we need a program to do, and your group will come up with a design to handle it. Your design will take the form of one or more class hierarchies, following the diagram style shown above.
One of the early inspirations for object oriented programming was the needs of programs for doing simulations. In fact, object oriented programming really began with a language called "Simula", which was designed for writing simulations. So, we're going to consider a problem that could be a part of a sophisticated program for doing financial simulations (in the world of personal finance ... I don't know anything about business-scale finance, being just a lowly professor). I want a program that will read in a file describing recurring events — like "every 14 days starting on 1/6/2016 I receive a paycheck" — and then simulate the day-by-day passing of time, printing out the events that occur in a day. [ Handout Form]
| in0.txt | first 64 lines of output |
every 14 days start 1/6/2016 income Paycheck every 1 months start 1/15/2016 expense Mortgage Due every 1 months start 1/6/2016 expense Cable Due every 3 months start 3/21/2016 expense Water/Sewer Due every 3 months start 3/26/2016 income Stock Dividend every 1 months start 1/23/2016 expense Credit Card Due every 1 months start 1/11/2016 expense Car Payment Due every 1 months start 1/2/2016 expense Car Insurance Due every 1 months start 1/17/2016 expense Cell Phone Due every 1 days start 1/7/2016 prob 0.143 expense Groceries every 1 days start 1/1/2016 prob 0.15 expense Dinner Out every 7 days start 1/3/2016 prob 0.5 expense Breakfast Out every 4 days start 1/1/2016 prob 0.5 expense Gas every 1 days start 1/1/2016 prob 0.01 expense Car Repair every 12 months start 4/15/2016 expense Taxes Due every 1 months for 12 start 1/16/2016 expense Lazy Boy Layaway Payment Due |
1/1/2016: Dinner Out, Gas 1/2/2016: Car Insurance Due 1/3/2016: Breakfast Out 1/5/2016: Gas 1/6/2016: Paycheck, Cable Due 1/7/2016: Groceries, Dinner Out 1/9/2016: Gas 1/10/2016: Breakfast Out 1/11/2016: Car Payment Due 1/13/2016: Groceries 1/15/2016: Mortgage Due 1/16/2016: Lazy Boy Layaway Payment Due 1/17/2016: Cell Phone Due, Breakfast Out 1/18/2016: Dinner Out 1/20/2016: Paycheck 1/21/2016: Gas 1/23/2016: Credit Card Due 1/24/2016: Groceries 1/25/2016: Gas 1/29/2016: Gas 2/2/2016: Car Insurance Due, Dinner Out 2/3/2016: Paycheck 2/5/2016: Dinner Out 2/6/2016: Cable Due, Dinner Out, Gas 2/7/2016: Breakfast Out 2/8/2016: Groceries 2/10/2016: Dinner Out 2/11/2016: Car Payment Due, Groceries 2/12/2016: Groceries, Dinner Out 2/14/2016: Breakfast Out 2/15/2016: Mortgage Due ... |
Some of the lines in the input file probably deserve some explanation.
every 3 months start 3/26/2016 income Stock Dividend
This indicates that "Stock Dividend" is an event that first occurs on 3/26/2016 and occurs every three months from that point on. So, for example, the next occurence would be 6/26/2016.every 14 days start 1/6/2016 income Paycheck
This indicates that "Paycheck" is an event that first occurs on 1/6/2016 and occurs every 14 days from that point on. So, for example, the next occurence would be 1/20/2016.every 7 days start 1/3/2016 prob 0.5 expense Breakfast Out
This indicates that every seventh day, starting at 1/3/2016, there is a 50% chance that the "Breakfast Out" event occurs. The probabalistic occurrence only happens with "every X days" events.every 1 months for 12 start 1/16/2016 expense Lazy Boy Layaway Payment Due
This indicates that " Lazy Boy Layaway Payment Due" is an event that first occurs on 1/16/2016 and occurs monthly from that point on until it has occurred 12 times. So, for example, the next occurence would be 2/16/2016, and the last occurrence would be 12/16/2016. The limit on the number of occurrences only happens with "every X months" events.
The system you're designing needs to be able to read all the events described in the sample input file, and any other file that follows the same basic format. The design itself should consist of one or more class hierarchies given in the same form as the diagram above.