CSE341 - Object-Oriented Programming -
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.
(see text for definitions)
- message protocol
- dynamic binding of message to method
- reusability; frameworks
Examples: ordering flowers; transportation simulation; window manager
Another metaphor: computation as simulation.
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
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
Characteristics of Simula:
- based on Algol-60 (very smooth integration though)
- hybrid language: not everything is an object
- classes, instances, inheritance
- block structure
- support for discrete event simulation
Characteristics of Smalltalk-72:
Characteristics of Smalltalk-80 (now also known just as Smalltalk):
- 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
Smalltalk is now a commercial product (ParcPlace/Digitalk, Object
Technology International, IBM Smalltalk).
- everything is an object, even classes, blocks (closures), activation
- classes can have subclasses
- not statically typed
- rich programming environment
- definitely no longer a programming language for kids!
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."
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.
- 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.)
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
- 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
- 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
- Specify messages that the objects should understand, and begin
- 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.)
Vehicle and a subclass
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
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
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
ISBN/Price: 0-8053-5340-2 Cloth Text $52.75 (Ingram Price), $51.75 (Net),
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 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
the patterns home page.
- command (make an object that represents a command -- the object can
then understand messages such as
- observer (used in model-view-controller)
- state (uses indirection to achieve different behavior for an object
depending on its state)
- 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
Are there frameworks to use?