Object-oriented programming (OOP) is a new programming paradigm that views computation as objects interacting by sending messages to one another. Key elements of OOP include objects performing computation by making requests of each other through message passing, with every object having its own memory consisting of other objects. Classes group similar objects and define their common behaviors. Classes are organized into an inheritance hierarchy to allow subclasses to inherit and override behaviors. OOP aims to help programmers cope with complexity by providing abstraction and modularity.

1. Principles of Object-Oriented Programming
 Why OOP is popular?
 Language and thoughts
 A new way of viewing the world
 Elements of OOP
 Coping with complexity

2. Difficult Questions
• What is Object-Oriented Programming?
• Why is it so popular?
– OOP is a revolutionary idea, totally unlike anything that has come before in
programming languages
– OOP is an evolutionary step, following naturally on the heels of earlier
programming abstractions

3. Why is OOP Popular?
A few possible reasons why OOP is popular:
• Hope that it will quickly and easily lead to increased productivity and
increased reliability (solve the software crises)
• Similarity to techniques of thinking about problems in other domains
• Hope for easy transition from existing languages (e.g., C or Pascal)

4. A New Paradigm
We start by considering the definition of the term ``paradigm'':
Par a digm n. 1. 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.]
OO programming is a new paradigm
• New way of thinking about what it means to compute, and about what we
can structure information inside a computer
Let’s first see the relationship between languages and thoughts

5. Language and Thoughts
In linguistics there is a hypothesis that the languages we speak directly
influence the way in which we view the world (called
Sapir-Whorf Hypothesis)
 Controversial example of languages influencing thoughts
– Eskimo (or Innuit) languages have many words to describe snow
– Arabic languages and camels
 Should not over-generalize the conclusion
– With time and training, we can also distinguish snow; however, our
language does not force me into doing so, so it is not natural to me
– Different languages can lead one (but does not require one) to view the
world in a different fashion
 This is also applicable to computer programming languages
– Using OO language can naturally lead one to view the world in OO fashion,
but does not force one to do

6. An Example from Computer Languages
 The programming language chosen to solve a problem will decide
fundamentally the way in which an algorithm is developed
– 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?) Fortran 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.

7. A Better Solution
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
...
TGGACCGGACCC
...
Ran surprisingly fast

8. What lead to the discovery?
Why did the APL programmer find the better solution?
• Fortran programmer was blinded by a culture that valued loops, simple
programs
• Sorting is a built-in operation in APL, so good APL programmers try to find
solutions based on sorting
• APL programmers were “naturally” led to better solutions
Programming language directs the programmer’s mind to view the problem
in certain way

9. Church's Conjecture
 Language affects the way of thinking is believable, but Sapir-Whorf
hypothesis is controversial
– It claims that it is possible for one working in one language to imagine
thoughts that cannot be translated or understood in different languages
 In computer science, we have a directly opposite assertion:
Church's Conjecture: Any computation for which there exists an
effective procedure can be realized by a Turing machine.
 Any programming language can simulate Turing machine
– All languages are equivalent, so anything can be done in any language
– But it may simply be easier or more efficient to use one language or another
 Power of OO programming languages should be understood in a
similar way; they make it easy to maintain large S/W projects

10. Imperative Programming Paradigm
Imperative programming is the ``traditional'' model of computation.
• State
• Variables
• Assignment
• Loops
A processing unit is separate from memory, and ``acts'' upon memory
– Computer is the data manager
– wandering through memory, pulling values in memory slots
– transforming them in some manner, and pushing results back in some other
slots
– Although this is exactly what happens inside a computer, it is not the way
people do for solving problems

11. Visualization of Imperative Programming
Sometimes called the ``pigeon-hole'' model of computation.

12. Recursive Design
The structure of the part mirrors the structure of the larger unit.

13. Alan Kay's Description of OO Programming
OO programming is based on the principle of recursive design.
1. Everything is an object
2. Objects perform computation by making requests of each other
through the passing of messages (bundled with arguments)
3. Every object has it's own memory, which consists of other objects.
4. Every object is an instance of a class. A class groups similar objects.
5. The class is the repository for behaviors associated with an object
6. Classes are organized into singly-rooted tree structure, called an
inheritance hierarchy.
We can illustrate these principles by considering how I go about
solving a problem in real life.

14. Illustration of OOP Concepts
- Sending Flowers to a Friend
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.
I can't deliver them myself. So I use my local Florist.
I tell my Florist (named Flo) the address for my friend, how much I want to spend,
and the type of flowers I wish to send.
Flo contacts a florist in my friends 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.
And so we see, that to solve my problem requires the interaction of an entire
community of individuals.

15. Elements of OOP – Objects
1. Everything is an object.
Actions in OOP are performed by agents, called instances or objects.
There are many agents working together in my scenario. We have
myself, my friend, the florist, the florist in my friends 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.

16. Elements of OOP – Messages
2. Objects perform computation by making requests of each other
through the passing of messages
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, I give a message to Flo.
She in turn gives a message to the florist in my friends city, who
gives another message to the driver, and so on.

17. Information Hiding
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.

18. Elements of OOP – Receivers
Messages differ from traditional function calls in two very important
respects:
• In a message there is a designated receiver that accepts the message (in
function calls, there is no receiver
• The interpretation of the message may be different, depending upon the
receiver

19. Different Actions
var
Flo : Florist;
Beth : Wife;
Ken : Dentist;
begin
Flo.sendFlowersTo(myFriend); { will work }
Beth.sendFlowersTo(myFriend); { will also work but in different way}
Ken.sendFlowersTo(myFriend); { will probably not work }
end;

20. Behavior and Interpretation
Although different objects may accept the same message, the actions
(behavior) the object will perform will likely be different.
Usually, the specific receiver for any given message will not be known
until run-time, so the determination of what behavior (code) to perform
may be made at run-time, a form of late binding.
• Different from early binding of name to code in function calls
The fact that the same name can mean two entirely different operations
is one form of polymorphism.

21. Responsibility and Non-interference
• Behavior is described in terms of responsibilities
• My message indicates only the desired outcome
• I do not want to interfere with how the florist achieves the outcome
• Responsibility is closely related to non-interference
• Implies greater independence between agents, which is a critical
factor in solving complex systems
• OOP is responsibility-driven software design process
• The difference between traditional and OO perspectives can be
summarized by the following:
``Ask not what you can do to your data structures, but ask what your
data structures can do for you''

22. Elements of OOP - Recursive Design
3. Every object has it's own memory, which consists of other
objects.
Each object is like a miniature computer itself - a specialized
processor performing a specific task.

23. Elements of OOP – Classes
4. Every object is an instance of a class. A class groups similar
objects.
5. The class is the repository for behavior associated with an
object.
The behavior I expect from Flo is determined from a general idea I
have of the behavior of Florists.
We say Flo 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.

24. Hierarchies of Categories
But there is more that I know about Flo then just that she is a Florist. I
know she 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.

25. Class Hierarchies

26. Elements of OOP – Inheritance
6. Classes are organized into a singly-rooted tree structure, called an
inheritance hierarchy
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.

27. Elements of OOP – Overriding
Subclasses can alter or override information inherited from parent
classes for exceptional cases
• All mammals give birth to live young
• Some mammals lays eggs

28. Summary: OOP View of Computing
The OOP view of computation is similar to creating a universe of
interacting computing objects
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.

29. Coping with Complexity
Another way to understand OOP is to place it in a historical context.
Non-linear behavior of complexity
– As programming projects become large, they tend to require a team of
programmers
– Interesting phenomenon: a task that takes 2 months with 1 programmer
requires more than 1 month even with 2 programmers
``software crises'' came out when people realized the major problem
in software development were not algorithmic, but were caused by
communication difficulties and the management of complexity.

30. Interconnections - the Bane of Complexity
Many software systems are complex not because they are large, but
because they have many interconnections.
Interconnections make it difficult to understand pieces in isolation, or to
carry them from one project to the next.
The inability to cleanly separate out components makes it difficult to
divide a task between several programmers.
Complexity can only be managed by means of abstraction, by
eliminating information that a programmer do not need to know.
If we examine the history of mechanisms used to solve the problem of
complexity we can better appreciate the role of OOP.

31. Assembly Languages
Assembly languages and linkers were perhaps the first tools used to
abstract features of the bare machine.
• Addresses could be represented symbolically, not as a number.
• Symbolic names for operations.
• Linking of names and locations performed automatically

32. Procedures and Functions
Libraries of procedures and functions (such as mathematical or
input/output libraries) provided the first hints of information hiding.
They permit the programmer to think about operations in high level
terms, concentrating on what is being done, not how it is being
performed.
But they are not an entirely effective mechanism of information hiding,
and they only partially solved the problem of multiple programmers
making use of the same names
An example - A stack

33. The Problem of Stacks
int datastack[100];
int datatop = 0;
void init() // initialize the stack
{ datatop = 0; }
void push(int val) // push a value on to the stack
{ if (datatop < 100)
datastack [datatop++] = val; }
int top() // get the top of the stack
{ if (datatop > 0)
return datastack [datatop - 1];
return 0; }
int pop() // pop element from the stack
{ if (datatop > 0)
return datastack [--datatop];
return 0; }

34. Block Scoping Didn't Solve the Problem
 Problems with previous implementation
– we need to use global variables for the array (no access control)
– method names cannot be used elsewhere
 More control over name visibility using block scoping in Algol and Pascal, but
any scope that accesses the four methods can access the data as well
begin
var
datastack : array [ 1 .. 100 ] of integer;
datatop : integer;
procedure init; ...
procedure push(val : integer); ...
function pop : integer; ...
...
end;

35. Modules
Modules basically provide collections of procedures and data with
import and export statements [Parnas 1972]
– they can distinguish public part that are accessible outside and private part
that are accessible only within the module
– Enforces need-to-know principle
Solves the problem of encapsulation -- but what if your programming
task requires two or more stacks?
– Only one stack can be manipulated with a module
– Need to define a different module for another stack- with what names?
Modules provide information hiding but do not allow instantiation, which
is the ability to make multiple copies of the data area
– need to develop a new concept

36. Abstract Data Types
An Abstract Data Type is a programmer-defined data type that can be
manipulated in a manner similar to system-provided data types
• Have the ability to instantiate many different copies of the data type.
• E.g., define stack as data type and instantiate it as many as you want
• Data type can be implemented using provided operations, without
knowledge of internal representation.
• Packages in CLU and Ada can define abstract data types

37. Objects - ADT's with Message Passing
Characteristics of Objects
• Encapsulation -- similar to modules
• Instantiation -- similar to ADT's
• Messages -- dynamic binding of procedure names to behavior
• Activity is initiated by a request to a specific object, not by calling a function (do
you call push with a stack and a data value, or do you ask a stack to push a data
value onto itself?)
• Added to message passing, overloading of names and reusing software
• Interpretation of message -- it depends on objects receiving it
• Push for stack and push for door are different
• Inheritance -- Allow different data types to share the same code
• Polymorphism -- Allow the shared code to be tailored to fit the specific
circumstances

38. Summary
• Object-oriented programming is not simply features added to a
programming language. Rather, it is a new way of thinking
• Object-oriented programming views a program as a community of agents,
termed objects. Each object is responsible for a specific task.
• An object is an encapsulation of state (data values) and behavior
(operations).
• The behavior of objects is dictated by the object class.
• An object will exhibit its behavior by invoking a method (similar to executing
a procedure) in response to a message.
• Objects and classes extend the concept of abstract data types by adding
the notion of inheritance.