Object-Oriented Programming - Introduction

Metaphor for object-oriented programming: objects that interact with each other by sending and receiving messages.

Objects have state and behavior. (Contrast this with Scheme, in which functions act on data structures.) Support for information hiding.

Some Concepts

method
receiver
message protocol
dynamic binding of message to method
class
instance
inheritance
reusability; frameworks

(see text for definitions)

Examples: ordering flowers; transportation simulation; window manager

Another metaphor: computation as simulation.

History

Simula -- developed by Kristen Nygaard and Ole-Johan Dahl at the Norwegian Computer Centre in the 60's. Intended as a language for writing simulations. (The Scandanavian school of object-oriented language design still places heavy emphasis on description and modelling.)

The Learning Research Group at Xerox Palo Alto Research Center (PARC) developed Smalltalk as a language for the Dynabook, during the 70s and early 80s. The Dynabook was a yet-to-be-developed "laptop of the future." Alan Kay, Dan Ingalls, Adele Goldberg were key players in the development of Smalltalk. They selected simulation as the metaphor for programming the Dynabook. Smalltalk was influenced by Lisp, Simula, Ivan Sutherland's Sketchpad.

If you're interested in history, see the History of Programing Languages conference proceedings. Also see Simula and Smalltalk by Ben Dugan (a term project from 505 several years ago that examines the social and political influences on the development of the Simula and Smalltalk languages.)

Characteristics of Simula:

based on Algol-60 (very smooth integration though)
hybrid language: not everything is an object
classes, instances, inheritance
compiled
block structure
co-routines
support for discrete event simulation

Characteristics of Smalltalk-72:

interpreted
extensible syntax: fred move up x inches
more object-oriented than Simula -- even integers are objects
'class' is an object (but a rather special one). No subclassing

Characteristics of Smalltalk-80 (now also known just as Smalltalk):

everything is an object, even classes, blocks (closures), activation records, etc.
classes can have subclasses
not statically typed
rich programming environment
definitely no longer a programming language for kids!

Smalltalk is now a commercial product (ParcPlace/Digitalk, Object Technology International, IBM Smalltalk).

Java

Started as Oak, a language for embedded consumer electronic applications, written by James Gosling.

Use with the Internet and applets: bytecode interpreters; JIT compilers

Java description (from Sun): "A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, dynamic language."

Object-Oriented Design

Programming in the small vs. programming in the large -- object-oriented programming of particular value for programming in the large.

Responsibility-driven design: characterize software in terms of behavior.

A component must have a small, well defined set of responsibilities.
A component should interact with other components as little as possible. (Alan's postscript: this is one of several goals, and must be balanced against clarity, ease of use and reuse, and efficiency.)

One design technique: walking through scenarios. Design team acts out the running of the application. Activities are identified and assigned to some component as a responsibility.

CRC cards (component, responsibility, collaborator): give components a physical representation for use in walking through scenarios.

Another approach (less formal but otherwise not all that different):

Given an application to be constructed or a system to be modelled:

Is there an existing application that can be adapted? Or is there a framework that can be used? If so, use them! In any case you will be using existing system classes for the lower-level parts of the application or simulation.
Identify the objects involved. If you are using an existing framework, this will give you strong hints about how to decompose the application into objects. However, exactly what is an object will depend on the application or what aspect of the system is to be modelled.
Identify relations among the objects, in particular part-whole relations. Other relations may include attribute, container, etc.
Identify classes of objects, and inheritance relations among these classes. Are there abstract superclasses that can be defined to capture common properties?
Specify messages that the objects should understand, and begin defining them.
Heuristic: nouns become objects, verbs become messages. (But see below -- this is just an initial guideline.)
Heuristic for inheritance: "is a" relation can be represented using inheritance. (Example: a chimpanzee is a primate, and a primate is a mammal, and a mammal is an animal, and an animal is a living thing.)

The part-whole and inheritance relations are often confused by new object-oriented programmers. Examples of each: we might have an abstract class Vehicle and a subclass Bus (inheritance relation). A Bus has parts such as an engine (which might be an instance of class Engine), a body, an electrical system, and so forth. Parts can in turn have subparts. Note that Engine isn't a subclass of Bus however!

Back to the heuristic: a bus is a vehicle, but an engine is not a bus.

First sketch out a general system design. After that many of these steps are best done interactively -- construct classes and some test instances, and begin defining and testing methods online. Include method stubs for methods not yet defined.

What should be represented as an object?

It is sometimes appropriate to make objects that represent processes, as well as program objects representing objects in the system being modelled. Example: should we make airplane objects that understand a "fly" message? Or should we make flights into objects?

Or in simulating a billiard game, we might make billiard ball objects that understand collide messages. But (less obviously) it might be appropriate to make Collision objects.

Aphorism: use objects to model entities in the application domain -- however, generally we will also need to introduce other objects that help us code the application.

Where should behavior go?

Examples: method to show a grahical object; lexical scanner. (A lexical scanner is the part of a compiler that takes an input string and divides it up into tokens.)

Should we implement 'show' as a method for Ball, or as a separate DisplayEngine object? Should we implement the scanner as an operation on Strings, or make a separate Scanner object?

Probably show should be a method for Ball, but there should be separate scanner object.

Other Object-Oriented Design Methodologies

Many of these: Booch, Rumbaugh, etc etc.

Checklists of things to do; diagramming methods, etc. See e.g.

Author:       Booch, Grady 
Title:        Object-Oriented Design with Applications
Edition:      2nd ed.
Publisher:    Benjamin-Cummings Publishing Company
Year:         1994
Pages:        589p.
ISBN/Price:   0-8053-5340-2 Cloth Text $52.75 (Ingram Price), $51.75 (Net),
              $51.95

Frameworks

Reusable collections of classes -- subclass from these and adapt them to construct an application. Examples: the Model-View-Controller framework; the file system.

These need to be built with care: what are the right superclasses? what are the right method stubs that let you specialize behavior easily? Generally, you have to build a couple of applications first to see what the right generalizations are.

Patterns

Patterns in object-oriented programming are idiomatic and recurring structures of objects. A recent book is a catalog of 23 design patterns:

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software," Addison-Wesley, 1994.

(An intellectual antecedent is the work in architecture of Christopher Alexander.)

Examples:

proxy
command (make an object that represents a command -- the object can then understand messages such as do and undo.
observer (used in model-view-controller)
state (uses indirection to achieve different behavior for an object depending on its state)
prototype
singleton
decorator (wrapper)

Object-oriented design and Building a Pinball game

What are the objects? pinballgame, ball, flippers, scoring device. What are the inheritance relationships? Make a Bumper class, with subclasses Flipper, Wall, ScoringThing, BlackHole, etc. Don't confuse inheritance and part/whole relationships -- for example, Ball is not a subclass of PinballGame!

Are there frameworks to use?