(Notes by Alan Borning)
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)
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 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:
fred move up x inches Characteristics of Smalltalk-80 (now also known just as Smalltalk):
Smalltalk is now a commercial product (ParcPlace/Digitalk, Object Technology International, IBM Smalltalk).
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.
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.
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.
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.
Many of these: Booch, Rumbaugh, etc etc.
Checklists of things to do; diagramming methods, etc. See e.g. Grady Booch, Object-Oriented Design with Applications, 2nd ed., Benjamin-Cummings, 1994.
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 Alexander.)
Examples:
do and undo. See also the patterns home page.