|CSC 153: Computer Science Fundamentals||Grinnell College||Spring, 2005|
|Laboratory Exercise Reading|
This reading outlines a object-oriented solution to a problem based on a famous program called Eliza, developed by Joseph Weizenbaum.
Now that we have seen some implementation of object oriented programming, it is time to develop our skills at solving problems from an object-oriented perspective. To do this well, we need to disregard what we know about functional problem solving and look at problems from a completely different viewpoint. In object-oriented problem solving, we first identify the objects and classes or objects within a problem, and then we identify the relationships among those objects and classes.
Pattern matching and transformation rules occur frequently in symbolic computation. The following patterns and corresponding response templates can be used to generate "conversations".
|---1 my singleWord ---2 me ---3||tell me about your singleWord|
|---1 i am ---2||i am sorry to hear you are ---2|
|---1 am i ---2||do you believe you are ---2|
|---1 you ---2 me --- 3||why do you think i ---2 you|
|---1||in what way|
In this table, the blank spaces in a pattern, denoted by subscripted dashes, can be filled in with any sequence of words. Similarly, singleWord represents exactly one word in a sentence. For example, these patterns might generate the following "conversation," where the responses are indented and in italics:
well my friend made me come here
tell me about your friend
he says i am depressed
i am sorry to hear you are depressed
i think i need help
in what way
i wonder if you would help me learning to program Scheme
why do you think i would help you
when i registered for the course i wondered am i crazy
do you believe you are crazy
Each of these statements and responses follows the template/response patterns given. For example, in the first statement:
well my friend made me come here
the presence of the word
my near the start of the sentence
with the word
me later on corresponds to the first pattern,
with the following matches:
|Pattern Element||Words from this Sentence|
After identifying these pattern elements for the first pattern, the Eliza program uses the corresponding response template. In this case, the program prints "Tell me about your friend. The first four of these words come directly from the template. For the final word, singleWord in the template was matched with the word "friend" in the above analysis.
Write a program to read responses from a user, apply a relevant pattern, and use the corresponding template to generate a response.
In 1966, Joseph Weizenbaum used this approach to write a program, called Eliza, which conversed by simply rearranging words and phrases following a reasonably large collection of patterns. In 1976, Weizenbaum noted he "was startled to see how quickly and how deeply people conversing with [ Eliza] became emotionally involved" in the conversation. People shared their hopes and secrets, and they became annoyed if other people looked over their shoulders or otherwise interrupted. Even when they knew Eliza was a program, they often talked as if it were a close personal friend.
In an overall session, a user will expect to type lines into the program and then to receive responses. While one might allow complex input, for the current purposes it suffices to limit each user statement to a single line and to ignore matters of capitalization and punctuation.
In addition to the patterns above, we could plan for more complex conversations by adding additional patterns and response templates. Also, it seems reasonable for the user to quit by typing "exit". The program then should respond "program terminated" and stop. Within the current context, it seems natural to consider this interaction as another pattern/response pair, with a special final action.
The following remarks outline a solution to this problem. The discussion follows the general approach of object-oriented programming (OOP), although the discussion may not be strictly object-oriented in all respects.
Object-oriented programming (OOP) depends upon such concepts as objects and classes, inheritance, methods, and communication between objects. OOP focuses on data structures and adds functionality (or processing capability), while procedural languages traditionally begin with processes.
An analysis of this problem identifies the following major objects:
|input line||-||with 1 line for each user's input|
|6 patterns||-||each of which which includes a template with text/words, wildcards, and singleword designators|
|6 responses||-||corresponding to the patterns, each includes a template with text/words, wildcards, and singleword designators|
|directory/table||-||which matches text/words with wildcards and singleword designators|
In this analysis, patterns and responses may be identified fairly easily, as the most important nouns in the problem statement. Similarly, an input line represents the data which a user enters, and thus is a natural candidate as a class. The directory/table may require additional thought.
In particular, one expects a pattern will report when a line has an appropriate form, and one expects a response to print the corresponding result. However, the question arises as to how a response will know which words correspond to various blanks or single words in a pattern. One approach would be to combine a pattern and response into a single processing entity. While this is a viable alternative, it places a great deal of processing within a single object. Separating patterns and responses seems more in spirit with the nature of this problem, but then communication of word sequences is needed. One solution to this problem introduces a directory, which keeps track of which words go with which blanks and single words. In this approach, a pattern needs not know how blanks or word sequences will be used -- it just needs to identify what words correspond to which sequence. Similarly, a pattern need not know details of how the input line is divided into pieces -- it just needs to retrieve relevant word sequences for a response. A directory/table serves this communication purpose in a convenient way.
Once these objects are identified, we consider how the objects communicate during processing. For example, the following diagram shows a sequence of messages that might arise if an input line matches pattern 2.
Within this context of object-oriented problem solving, the main program performs two main tasks: creation of major objects and coordination of message passing.
Other tasks in processing are handled when individual objects respond to messages using the appropriate methods.
The development of a class proceeds by identifying what data an object contains and what messages an object might receive.
A constructor for a class should provide a mechanism for initializing each object in a way that seems natural for the problem. For example, the statement of the Eliza program involves patterns and responses, given in a table, so it is desireable to follow a similar structure for the corresponding constructors. For example, the following shows reasonable Scheme and C++ declarations for the first pattern and response in the above problem:
(let* (... (pat1 (pattern "__1" "my" "singleWord" "__2" "me" "__3")) ... (resp1 (response "tell me about your" "singleWord")) ))
Pattern pat1 ("__1", "my", "singleWord", "__2", "me", "__3"); Response resp1 ("tell me about your", "singleWord");
Since each method for an object must handle only one type of message, the coding for each method usually is relatively simple. In particular, a method must handle only the appropriate work within an object and, perhaps, send messages to other objects for processing there. With this limited scope, code for a method often is quite short.
Programs following this object-oriented approach to the Eliza problem are available in both Scheme and C++:
This document is available on the World Wide Web as
created January 17, 2000
last revised February 9, 2005
|For more information, please contact Henry M. Walker at firstname.lastname@example.org.|