Introduction to Object-oriented Programming

CMPS 2143

2

Objectives

1. Investigate and explain basic principles of OOP

2. Look at a little theory and history

3

History•OOP and Simula developed in 1960s (Norway)•Alan Kay in 1970s developed Smalltalk

•Caught on in 1980s▫Seminal paper in Byte in 1981 on Smalltalk▫Extension to C at Bell Labs in 1982▫1st OOP conference in Oregon in 1986

•Objective-C (1986), Actor (1987), Eiffel (1988), Object Pascal, Lisp dialects

• Java 1991 and C++ in 1994

4

Why is OOP Popular?

•OO solutions scale well•Supports abstraction understanding• Libraries reusability

Language and Thought

• Linguistic theory states: structure of language defines boundaries of thought ?TRUE?

• Language can facilitate or impede certain modes of thought

•A given programming language can influence class of solutions▫Example: DNA sequence analysis in Fortran vs APL

5

6

Church and Whorf’s conjectures•Several programming paradigms/language formalisms▫Church, Post, Markov, Turing, Kleene, etc.

•Church: In a fundamental way all programming languages are identical

•Sapir-Whorf: It is possible to have ideas that can be expressed in one language that cannot be expressed in another

•OO techniques do not provide any new computational power, but do make it easier to address certain problems

7

The OOP Paradigm

•Programming paradigm – a way of conceptualizing how to perform a computation and how tasks are structured and organized

•The OO Paradigm not new – Biologist Linnaeus categorized biological organisms using ideas of phylum, genus, species, etc.

•Easy for novice programmers to grasp ideas of OOP▫Natural view of world

8

OOP in a Nutshell

•A program models a world of interacting objects.

•Each object has a role to play and provides a service or performs an action for other members in world

9

Example

10

OOP in a Nutshell

•Objects create other objects and “send messages” to each other (ie, call each other’s methods).▫Calling object need not know actual means of how

request will be honored

•Each object is an instance of a class; a class defines properties of its objects and their responsibilities.

•The data type of an object is its class.

11

Another view of OOP

•Review the main OOP concepts: ▫encapsulation

▫abstraction

▫inheritance▫polymorphism

12

Encapsulation and Instantiation

Classes provide two very important capabilities:•Encapsulation - The purposeful hiding of

information, thereby reducing the amount of details that need to be remembered/communicated among programmers.

• Instantiation - The ability to create multiple instances of an abstraction.

13

Encapsulation: SeparatingInternal and External Views

14

Responsibility & Abstraction

•Discussing a problem in terms of responsibilities increases the level of abstraction and permits greater independence between agents

•This is a standard powerful form of abstraction sometimes called information hiding

15

Another view of OOP

•Review the main OOP concepts: ▫abstraction▫encapsulation

▫inheritance▫polymorphism

16

Inheritance• Inheritance implements the “is a” relationship.

•Not to be confused with embedding (an object has another object as a part), which represents the “has a” relationship:

A sailboat is a boat

A sailboat has a sail

17

Inheritance

•A class can extend another class, inheriting all its data members and methods while redefining some of them and/or adding its own.

•A class can implement an interface, implementing all the specified methods.

18

Inheritance (cont’d)• In C++ and Java, a subclass can extend only one

superclass.

• In Java, a subinterface can extend one superinterface

• In Java, a class can implement several interfaces — this is Java’s form of multiple inheritance.

19

Class Hierarchies• Inheritance leads to

a hierarchy of classes and/or interfaces in an application:

20

Class Hierarchies cont.•Example from Swing:

JComponent

... ... ... JTextComponent

JTextField JTextArea JEditorPane

JPasswordField JTextPane

21

Another view of OOP

•Review the main OOP concepts: ▫abstraction▫encapsulation

▫inheritance▫polymorphism

22

Method Binding and Polymorphism

•When Fred asks his wife Beth to send some flowers to Robin for her birthday she might use a different method than the florist Fred

•The method that gets executed in response to a message depends on the receiver of the message.

•Different methods that can execute in response to the same message is a form of polymorphism

23

Sending Messages vs. Procedure Call

•A message has a designated receiver (some object)

•The interpretation of the message is determined by the receiver and can vary amongst different receivers.

•Often the actual receiver of a message is not known until run-time. There is late or dynamic binding between the message and the code fragment (method) used to respond to the message

24

Functions are not MethodsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not FunctionsMethods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions

25

Abstraction mechanisms in programming languages•Procedures and Functions (function centered

view)+ information hiding for the detail of the behavior- no information hiding for the detail of the data- no encapsulation

•Modules and Packages (data centered view)+ information hiding+ encapsulation- instantiation not always supported

•Abstract Data Types+ separates interface and implementation

26

References•Budd Book