Reading

Required: These notes!
Recommended: Java in a Nutshell, TO APPEAR

Overview

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().

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.

The system you're designing needs to be able to read all the events described int he 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.