Introduction To OOP - UMBC

processroguishSoftware and s/w Development

Nov 18, 2013 (3 years and 6 months ago)

52 views

UMBC

1


Continuing OOP

Introduction


Lecture 2




CMSC 432

Shon Vick

UMBC

2

Objectives

1.
Review some ideas from last time

2.
Explain what is meant by
encapsulation and abstraction

3.
Describe various uses for classes in
object
-
oriented programming.

4.
Distinguish between the interface
and implementation parts in Java/C++

5.
Write the interface and
implementation parts for a simple
program.

UMBC

3

OOP in a Nutshell:


A program models a world of interacting
objects.


Objects create other objects and “send
messages” to each other (in Java, call
each other’s methods).


Each object belongs to a class; a class
defines properties of its objects. The
data type of an object is its class.


Programmers write classes (and reuse
existing classes).

UMBC

4

Alternate View of OOP Tenets

by Alan Kay


Everything is an object


Computation is performed by objects
communication with each other, requesting
that others perform action


Objects communicate by sending and
receiving messages. A message is a request
for action bundled with whatever argument
is necessary to complete the task


Each object has its own memory which
consists of other objects

UMBC

5

Another view of OOP


Review the main OOP
concepts:


inheritance


abstraction


encapsulation


polymorphism


UMBC

6

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.


Inheritance implements the “is a”
relationship between objects.


UMBC

7

subclass

or

derived class

superclass

or

base class

extends

Inheritance (cont’d)

subinterface

superinterface

extends

class

interface

implements

UMBC

8

Inheritance (cont’d)


In 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
.

UMBC

9

Inheritance (cont’d)


An abstract class can have code for
some of its methods; other methods are
declared
abstract
and left with no code.


An interface only lists methods but does
not have any code.


A concrete class may extend an
abstract class and/or implement one or
several interfaces, supplying the code
for all the methods.


UMBC

10

Inheritance (cont’d)


Inheritance plays a dual role:


A subclass reuses the code from the
superclass.


A subclass (or a class that implements an
interface) inherits the
data type

of the
superclass (or the interface) as its own
secondary type.


UMBC

11

Inheritance (cont’d)


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


Game

GameFor2

BoardGame

Chess

Backgammon

Solitaire

UMBC

12

Inheritance (cont’d)


Example from Swing:





JComponent


... ... ... JTextComponent


JTextField JTextArea JEditorPane


JPasswordField JTextPane

UMBC

13

Inheritance (cont’d)


An object of a class at the bottom of a
hierarchy inherits all the methods of all
the classes above.


It also inherits the data types of all the
classes and interfaces above.


Inheritance is also used to extend
hierarchies of library classes, reusing
the library code and inheriting library
data types.


UMBC

14

Inheritance (cont’d)


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


UMBC

15

Summary (cont)


Every object is an instance of a class. A class
represents a grouping of similar objects.


The class is the repository of the behavior
associated with an object. That is all objects that
are instances of the same class can perform the
same actions


Classes are organized in a single rooted tree
structure called the inheritance hierarchy.
Memory and behavior associated with a class are
automatically available to any class that is a
descendant in this inheritance hierarchy

UMBC

16

Coping with Complexity


Interconnectedness, the dependence of
one portion of code on another portion, is
responsible for this phenomena


Abstraction mechanisms try to cope with
this and object oriented techniques offer
yet another step forward


UMBC

17

Method Binding and

Polymorphism


When Fred would ask 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. Getting
different methods executes in
response to the same message is a
form of
polymorphism


UMBC

18

Sending Messages

vs. Procedure Call


A message has a designated receiver (some
object)


The interpretation of the message, I.e. the
method used in response to 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

UMBC

19

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 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 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 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 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 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 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 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 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 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 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 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 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 Functions Methods are not Functions

Methods are not Functions Methods are not Functions Methods are not Functions Methods are not Functions



Functions are not Methods

UMBC

20

Responsibility &

Abstraction


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

between agents


The entire collection of responsibilities
associated with an object is often described by
the term
protocol


A receiver takes responsibility for responding to
a message; the sender of the message need not
know the details of the method used. This is a
standard powerful form of abstraction
sometimes called
information hiding





UMBC

21


Categories surrounding Fred


Material Object


Animal



Mammal



Human








Shopkeeper






Florist

Fred

UMBC

22

Classes and Instances


Although Chris does not know Fred very he has a
rough idea of the transactions that occur inside
Fred’s shop. Chris is able to make certain
assumptions based on previous experiences with
florists. He expects that Fred, being an instance
of the category florist, will match the pattern.


All objects are instances of a class. The method
invoked by an object to respond to a message is
determined by the class of the receiver. All
objects of the same class use the same method in
response to the same message.

UMBC

23

A Material Objects Class
Hierarchy

Sam

Dog

Fred

Florist

Shopkeeper

Ken

Potter

Artist

Human

Phyl

Platypus

Mammal

Animal

tulip1

tulip2

tulip 3

Tulip

Flower

Plant

Material Object

UMBC

24

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
.


UMBC

25

Encapsulation: Separating

Internal and External Views

Push




const

limit

=

300
;

Pop





var

currentTop

:

0

..

limit
;

Top





values

:

array

[

1

..

limit]

of

integer
;


















UMBC

26

State
-

Instance Variables



We have been using the term instance to
mean a representative or an example of a
class.


We will use the term instance variable to
represent the state, or data values
maintained internal to a class.


We can record information about the
instance variable on the back side of a CRC
card, since it is internal to a class.


Clients can see the front of the card,
implementers can see the backside
.


UMBC

27

Interface and

Implementation

In

most

OOP

languages,

the

distinction

between

interface

and

implementation

is

manifest

on

two

distinct

levels
:


Within

a

class,

separation

between

interface

and

implementation

part

Example,

in

C++,

public

and

private

fields
.


Interface

descriptions

and

implementation

bodies

appearing

in

separate

files

(or

separate

area

of

same

file)
.

Example,

in

C++,

*
.
h

files

and

*
.
cpp

files
.


UMBC

28

End of Lecture

UMBC

29

Abstraction



Abstraction mechanisms are techniques to
deal with creating, understanding and
managing complex systems


Abstraction is the purposeful suppression
or hiding of some details of a process or
artifact in order to bring out more clearly
other aspects, details or structures


Through abstraction one builds a model of
the actual system


UMBC

30

Abstraction layers in OOP


At the highest level a program is viewed as a
community of cooperating objects.


Each object in this community provides services


At this highest level the important features are
the services provided by each object and the lines
of cooperation and communication between them.


The next level of abstraction allows a group of
objects working together to be grouped in a unit
(packages, name spaces, units) allowing some names
to be exposed to the world outside the unit while
others remain hidden inside the unit


UMBC

31

Abstraction layers in OOP


The next two levels of abstraction deal
with the interaction between 2 individual
objects where one (the
client
) uses
services from the other (the
server
)


The server advertises the services it can
provide for the client as an interface, the client
programs to this interface


The server provides a concrete implementation
for its interface


The last level of abstraction considers a
single task in isolation I.e. which steps
implement a single method


UMBC

32

General Forms of Abstraction




abstraction

division into parts

“has a”

multiple views

Specialisation

“is a”

catalogs

repetition

service view

class hierachies

ADT

OO programs

patterns

composition

recursive data structures

recursive algorithms

dictionaries

cross
-
references

UMBC

33

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

UMBC

34

Abstraction mechanisms in OO
programming languages


Classes are as Abstract Data Types in a
service
-
centered

view


Message Passing and Method Binding bring
polymorphism leading to more readable
code


Class Hierarchies and Inheritance bring
code sharing which results in increased
functionality and reduction of code size


Inheritance and polymorphism together
allow for tailoring shared code

UMBC

35

Object Oriented Design


Object oriented software development is NOT
about the syntax of a programming language


Object oriented software development is about a
design technique driven by the determination and
delegation of responsibilities


Responsibility implies non
-
interference, it cuts or
reduces the links between objects that depend on
implementation details


Goes beyond information hiding and encapsulation
when dealing with programming in the large

UMBC

36

References


Classes and Methods


OOP Introduction


OOP Concepts


Budd Book