OOP Design and Design Process


The very high level view

There are two classes of 'customer' that need to be satisfied in the software development process. These groups have very different concerns. All programming methodologies and tools, including OOP primarily address the need of the project managers and developers (who not coincidently who the methodologies and tools are sold to).

The high level view

What ideas do we have to achieve the goals described above?

The view from Java

What tools do we have to support these concepts.

OOP Design: Object Relationships

One of the skills to learn in OOP design is when to use inheritance vs interfaces. Diceding whether something shoulf be a subclass or instance variable. etc.

While there are no hard and fast rules. There are some general principles and advice. One key is to think about the relationships of the objects involved. There are (at least) four major relationships in OOP programmion: IS-A, HAS-A, USES, and BEHAVES-LIKE. The meanimg of these relationships is exactly what it is in English.

Software Development Process (part 1)

In the remaining time, we will examine the design process for a small to medium size system, one with no major subsystem capable of being built by one or two people is a short amount of time. We will discuss the design process for multi-module system, and larger teams later in the course.


Maxim: "Think first, program last"

The "think first" part of the development process is also known an the design stage. In this stage we need to plan out what we need to build without actually building it. The OOP design process is pretty much the same as any other, except it places a greater emphasis on data. In OOP design, the class hierarchy comes first, then the algorithms (methods).

There are several stages to the design process. To make them concrete we will develop a running example: writing the game Tetris. At first glance, this is a daunting project. We shall see if we can make it more managable.

Our design process will be mainly top-down, in that we will design our system in terms of classes and methods we wish we had, then we will implement those classes and methods. (Occasionally, a bottom-up approach is called for, especially when a method or algorithm looks like it will be difficult to implement. In this case it might be worthwhile to implement the trouble spots and see how this implementation affects the design so far.}


More design examples. Emphasize IS-A, HAS-A, BEHAVES-LIKE, and USES