Lecture Notes on Object-Oriented Programming

Metaphors

• Hard boiled eggs
• Little black boxes
• Widget factories

All are necessarily incomplete, imperfect. The best might actually be a person. This makes anthropomorphizing very easy. This metaphor requires a multi-threaded OO model – interesting, but a bit more complicated to start with.

A Simple Example

(from Bruce Webster, Pitfalls of OO Development)

Suppose you bought a nifty device at Radio Shack, a Weather Clock. This device tells you the time, temp, pressure and humidity. Looking at your Radio Shack purchase you would see four gauges telling you the four pieces of data. You wouldn’t know what’s inside the device, or how the numbers being displayed were determined. The implementation of getting this data is encapsulated. All you see (and all you want/need to see) is the interface. Someday RS may change one of their gauges to be more accurate, or cheaper. They wouldn’t have to change the interface, and the user would never know a change took place.

What if you want two weather clocks, one for the living room and one for the kitchen? Just buy another instance of the nifty RS device – own two of them. They are distinct, show different data, reside in different places, have different identities, but they are two of the same thing, a Weather Clock. Just because you own two of them doesn’t mean that RS had to re-invent a new Weather Clock. They just ran another on off the factory for you. Since you already owned one of them, using the new one in the kitchen is easy – the interface is identical. Is the implementation the same?

What if you go back to RS and buy a Digital Watch. Suppose RS to save money uses the same time keeping mechanism and interface in both the watch and the weather clock. We can classify these devices by recognizing what makes them similar: they are both types of Time Pieces. The Digital Watch only keeps time. The Weather Clock does some more stuff, but it too keeps and displays time. Do you think that Radio Shack likes the idea of re-designing the time keeping mechanism and time-showing mechanism for these two products? No, so they re-use that part. We do this in OO by forming an inheritance hierarchy. You may have heard the term “isa” for this hierarchy, since we can say that WeatherClock isa TimePiece. (Note that in this case it might be better to say WeatherClock is-at-least-a TimePiece.)

Figure: inheritance hierarchy for TimePiece, DigitalWatch, WeatherClock

• What’s in TimePiece?
• What’s in DigitalWatch?
• What’s in WeatherClock?
• Would anybody buy a TimePiece product?

Suppose you have a serial interface to the devices. You want to get the current time from them. In OO speak you send a message. Does the message need to be different? No, why should it be, when it is asking for the same information?

Suppose RS sells a barometer and a humidity gauge. Wouldn’t it be a drag to have to reinvent the wheel and have two barometers, one for standalone use and one to embed in the Weather Clock? Can we avoid this with inheritance? Nope, we need another means: composition. We can embed or include or compose one object in another.

Object-Oriented Programming

Programs are organized as collections of cooperative, dynamic objects, each of which is an instance of some class. The classes may be organized into a hierarchy formed from inheritance relationships.

To be OO, an implementation/language, must use/have these fundamental features.

OO programs may be written in non-OO languages, though it is usually very cumbersome to do so.

Object-Oriented Design

A means and a notation to applying an object-oriented decomposition resulting in logical and physical, static and dynamic models of the system being created.

The logical model is comprised of the classes and objects.

The physical model is comprised of the set of modules and processes.

Object-Oriented Analysis

A method of analysis which describes the problem domain in terms of classes and objects.

OOA feeds OOD which then can be implemented with OOP. In practice, these separate activities are usually done in an iterative fashion, with more analysis and less implementation up front, then more design, and finally more concentration on implementation. In other words, OO doesn’t magically make waterfall work any better than it does in structured design.