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 approach. To do this well, we need to disregard what we know about functional problem solving and look at problems from a completely different perspective. Rather, we identify the objects and classes of objects within a problem, and we need to identify the relationships among those objects and classes.
This lab outlines a object-oriented solution to a problem based on a famous porgram called Eliza, developed by Joseph Weizenbaum.
Problem: Pattern matching and transformation rules occur frequently in symbolic computation. The following patterns and corresponding response templates can be used to generate ``conversations''.
| Pattern | Response Template | |
|---|---|---|
| ---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. A single word is filled in for singleWord. For example, these patterns might generate the following ``conversation,'' where the responses are indented and in italics:
Sample Dialogue:
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
Task: Write a program to read responses from a user, apply a relevant pattern, and use the corresponding template to generate a response.
Historical Note: 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.
General User Interaction
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.
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.
Some Comments Regarding An Object-Oriented Solution:
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.
Role of the Main Program: In this context, the main program:
creates major objects
coordinates message passing
Other tasks in processing are handled when individual objects respond to messages using the appropriate methods.
Programming Notes:
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:
Scheme:
(let* (...
(pat1 (pattern "__1" "my" "singleWord" "__2" "me" "__3"))
...
(resp1 (response "tell me about your" "singleWord"))
))
C++:
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.
Coded Solutions: 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
http://www.math.grin.edu/~walker/courses/153.sp00/lab-oop-eliza.html
created January 17, 2000 by Henry Walker
last revised January 17, 2000