How To Design And Code Object-Oriented Programs

HOW TO DESIGN AND CODE OO PROGRAMS jmanley 12/1/04

This document attempts to provide guidance on how to design and code simple OO programs. It contrasts OOP design and coding with design and code of procedural programs. In doing so it also

elaborates on our CODING STANDARD.

The major points covered are:

* Analysis and Design

* Coding your program in small steps

* Minimum documentation

* Coding style

1. DESIGN

For both OO and procedural programs you need to insure that you satisfy the client's REQUIREMENTS.

You are designing an automated solution to a problem. Understand the problem. We all want Quality in our programs. The definition of quality is elusive. However there is general agreement that it always means SATISFYING THE USER'S REQUIREMENTS.

Once you think that you understand the requirements, for procedural programs a good and simple approach is to determine the required OUTPUT first. Then determine what INPUTS you have to work with. Finally come up with what "PROCESS" (algorithm) you will employ to produce the output from the inputs. In doing this you design the program as a collection of modules (or functions), preferably single-tasked.

Many find that it helps to draw a diagram(s). Writing pseudocode as program comments right in the editor is also a great approach. Pseudocode means English-like expressions. Some call it Structured English. A VERY brief statement for each step you envision is pseudocode.

These approaches continue to work for the methods (functions) in OO programs. But for the overall OO program there is the added need to select classes along with their attributes and behavior and the relationships between the classes. (See OO A&D handout for a thorough discussion of classes, attributes, behavior and the relationships between the classes and objects.)

A good starting point for simple OO programming should be "what do I want to automate"? There should be a "problem set" or problem statement from which you developed some specific requirements. This is often called "analysis" - the "what" phase. In OO analysis you come up with the candidate classes, each with its attributes and behavior. You also come up with any relationships between these likely classes and objects. Reviewing your problem statement and selecting nouns as candidate classes and/or attributes and selecting verbs as candidate methods is a simple but effective technique. A more formal approach employs modeling using Use Cases and UML diagrams for aiding this effort. Then you come up with an initial design, the "how" phase, which further refines what you have done and ties it to coding. Keep in mind that with OO, this is typically an incremental and iterative process.

How about an example? Our simple problem statement is to automate a checkbook. Our system will record transactions in a very simple, automated checkbook for one day. The next transaction could be a deposit or a withdrawal. The checkbook is balanced after each transaction.

How this problem set is fleshed out helps determine likely classes and their attributes and behavior. Checkbook looks like a candidate class. It could have attributes of at least transaction type, transaction amount and balance. Minimum behavior, in addition to setters and getters for the attributes, might be to calculate the balance and record the transaction (you'll get to setters and getters shortly).

Additional classes might be the customer whose checkbook it is and a date class which will provide the transaction date. Again keeping things extremely simple, class Customer might have one attribute of name and class Date, today's date. The relationship could be that Checkbook needs both Customer and Date (the other way around is not true. Nor do Customer and Date need each other.) To carry out this "association" relationship, these additional classes could become attributes of the Checkbook class, along with three we already selected.

Even this very simple application results in a lot of OO code. See an implementation of this problem statement in CheckBookSystem.java. It provides a good model of a simple OO program.

You are correct if you conclude that any application that abstracts/models, even very simple real problems, will have multiple classes. Unfortunately, most text's authors, especially in their initial chapters, resort to using one class, stand-alone programs which depend only on the classes built into Java. Making matters worse, often the one class has main as the only programmer-designed method. And in doing that they make main one very long method. Just slightly more advanced programs have additional methods called by main, but still everything is in the one class. This is probably in order to keeps things simple. I do it as well. But the downside is that it misleads the student and builds bad habits right from the start. These techniques are not really OO programming.

To learn OO, you want to think in terms of classes and their objects and their interaction, as we did in the above example. Little by little, you want to use more and more existing Java classes from the Java library of classes (the Application Program Interface - API). We just needed to use the Java lang "package" (more on packages later). But the point is that in addition to using the Java library of classes, you also want to design your own classes. When you design and code a new class, intend (pretend) that it will be put in your own API/library for later re-use - along with the other classes you write. Your goal is to write as little new code as possible when you code a project. You want to re-use the classes you already have. So pretend that each class you design and code was already done and is stored in an API. Now you just need to make use of those classes and design and code a "driver", "shell", "system" class that makes use of those other classes. In our example it is the CheckBookSystem class.

Parenthetically, this idea of re-use is why, as you do your analysis and design, a class and their methods should be kept as single-tasked as possible. This promotes reuse.

Later you will also design and code a GUI front-end and a file I/O and/or database access back end for your application. With this in mind, as much as possible, one should also