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

(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:

Characteristics of Smalltalk-72:

Characteristics of Smalltalk-80 (now also known just as Smalltalk): 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.

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:

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:

See also the patterns home page.

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?