Outline
Other Material
What is a paradigm? Why is this term used to describe the object-oriented approach to problem solving?
How does language influence thought?
What are some of the characteristics of the object-oriented way of thinking?
We start by considering the definition of this term:
Par a digm n. A list of all the inflectional forms of a word taken as illustrative example of the conjugation or declension to which it belongs. An example or model. [Late Latein paradigma, from Greek paradeigma, modern paradeiknunai, to compare, exhibit.]
What is the world does this have to do with computer programming languages?
What is true of natural languages is even more true of artificial computer languages
A student working in DNA research had the task of finding repeated sequences of M values in a long sequence of values:
ACTCGGATCTTGCATTTCGGCAATTGGACCCTGACTTGGCCA ...
Wrote the simplest (and therefore, most efficient?) program:
DO 10 I = 1, N-M
DO 10 J = I+1, N-M
FOUND = .TRUE.
DO 20 K = 1, M
20 IF X[I+K-1] .NE. X[J+K-1] THEN FOUND = .FALSE.
IF FOUND THEN ...
10 CONTINUE
Took a depressingly long time.
A friend writing in APL found a much better solution by rearranging the data and sorting.
A C T C G G positions 1 to M C T C G G A positions 2 to M+1 T C G G A T positions 3 to M+2 C G G A T T positions 4 to M+3 G G A T T C positions 5 to M+4 G A T T C T positions 6 to M+5 . . . T G G A C C G G A C C C . . .
Ran surprizingly quickly, thesis saved.
Why did the APL programmer find the better solution?
But what about the Sapir-Whorf hypothesis, that says there are some thoughts you can express in one language that you cannot express in another?
In computation we have the following assertion:
Church's Conjecture: Any computation for which there exists an effective procedure can be realized by a Turing machine language.
Anything can be done in any language, but it may simply be easier or more efficient to use one language or another.
Would YOU want to write an event-driven GUI interface in Turing machine?
Bottom line: Languages lead you, but do not prevent you from going anywhere you want.
So, what are the paradigms of programming?
Imperative programming is the ``traditional'' model of computation.
A processing unit is separate from memory, and ``acts'' upon memory.
Sometimes called the ``pigeon-hole'' model of computation.
Why not build a whole out of pieces that were similar at all levels of detail? (Think of fractals).
Idea: A program can be build out of little computing agents.
The structure of the part mirrors the structure of the larger unit.
Object-oriented programming is based on the priciple of recursive design.
We can illustrate these principles by considering how I go about solving a problem in real life.
To illustrate the concepts of OOP in an easily understood framework, consider the problem of sending flowers to a friend who lives in a different city. Chris is sending flowers to Robin.
Chris can't deliver them directly. So Chris uses the services of the local Florist.
Chris tells the Florist (named Fred) the address for Robin, how much to spend, and the type of flowers to send.
Fred contacts a florist in Robins city, who arranges the flowers, then contacts a driver, who delivers the flowers.
If we start to think about it, there may even be other people involved in this transaction. There is the flower grower, perhaps somebody in charge of arrangments, and so on.
Furthermore, any nontrivial activity requires the interaction of an entire community of objects working together.
Each object has a part to play, a service they provide to the other members of the community.
So we have Kay's first principle.
Actions in OOP are performed by agents, called instances or objects.
There are many agents working together in my scenario. We have Chris, Robin, the florist, the florist in Robins city, the driver, the flower arranger, and the grower. Each agent has a part to play, and the result is produced when all work together in the solution of a problem.
And principle number 2:
Actions in OOP are produced in response to requests for actions, called messges. An instance may accept a message, and in return will perform an action and return a value.
To begin the process of sending the flowers, Chris gives a message to Fred. Fred in turn gives a message to the florist in Robins city, who gives another message to the driver, and so on.
Notice that I, as a user of a service being provided by an object, need only know the name of the messages that the object will accept.
I need not have any idea how the actions performed in response to my request will be carried out.
Having accepted a message, an object is responsible for carrying it out.
Messages differ from traditional function calls in two very important respects:
var
Fred : Florist;
Elizabeth : Friend;
Ken : Dentist;
begin
Fred.sendFlowersTo(myFriend); { will work }
Elizabeth.sendFlowersTo(myFriend); { will also work }
Ken.sendFlowersTo(myFriend); { will probably not work }
end;
The same message will result in different actions, depending upon who
it is given to.
Although different objects may accept the same message, the actions (behavior) the object will perform will likely be different.
The determination of what behavior to perform may be made at run-time, a form of late binding.
The fact that the same name can mean two entirely different operations is one form of polymorphism, a topic we will discuss at length in subsequent chapters.
Each object is like a miniature computer itself - a specialized processor performing a specific task.
It is important that objects be allowed to perform their task however they see fit, without unnecessary interactions or interference with other objects.
The behavior I expect from Fred is determined from a general idea I have of the behavior of Florists.
We say Fred is an instance of the class Florist.
Behavior is associated with classes, not with individual instances. All objects that are instances of a class use the same method in response to similar messages.
But there is more that I know about Fred then just that he is a Florist. I know he is a ShopKeeper, and a Human, and a Mammal, and a Material Objects, and so on.
At each level of abstraction I have certain information recorded. That information is applicable to all lower (more specialized) levels.
Information (data and/or behavior) I associate with one level of abstraction in a class hierarchy is automatically applicable to lower levels of the hierarchy.
Subclasses can alter or override information inherited from parent classes:
Because the OOP view is similar to the way in which people go about solving problems in real life (finding another agent to do the real work!), intuition, ideas, and understanding from everyday experience can be brought to bear on computing.
On the other hand, common sense was seldom useful when computers were viewed in the process-state model, since few people solve their everyday problems using pigeon-holes.
``Unlike the usual programming method -- writing software one line at a
time-- NeXT's ``object-oriented'' system offers larger building blocks
that developers can quickly assemble the way a kid builds faces on Mr.
Potato Head.''
