2 1 OOP Introduction

8/8/2019 2 1 OOP Introduction

1/36

UMBC

1

Continuing OOPContinuing OOP

IntroductionIntroductionLecture 2Lecture 2

CMSC 432Shon Vick


2/36

UMBC

2

Objectives

1. Reviewsome ideas from last time2. Explain what is meant by

encapsulation and abstraction3. Describe varioususes for classes in

object-oriented programming.4. Distinguish between the interface

and implementation parts in Java/C++5. Write the interfaceand

implementation parts for asimple

program.


3/36

UMBC

3

OOP in a Nutshell:

h Aprogram modelsaworld of interactingobjects.

h Objects create other objectsand sendmessages to each other (in Java, calleach others methods).

h Each object belongs to a class;a classdefinesproperties of its objects. Thedata type of an object is its class.

h Programmerswrite classes (and reuse

existing classes).


4/36

UMBC

4

Alternate View of OOP TenetsbyAlan Kay

h Everything isan object

h Computation isperformed by objects

communication with each other, requestingthat othersperform action

h Objects communicatebysending andreceiving messages.A message isa requestfor action bundled with whatever argumentis necessary to complete the task

h Each object has its own memorywhich

consists of other objects


5/36

UMBC

5

Another view of OOP

h Review the main OOPconcepts:

h inheritance

h abstraction

h encapsulationh polymorphism


6/36

UMBC

6

Inheritance

h A class can extend another class,inheriting all its data membersandmethodswhile redefining some of themand/or adding its own.

h A class can implement an interface,implementing all thespecified methods.

h Inheritance implements the isarelationshipbetween objects.


7/36

UMBC

7

subclass

or

derived class

superclass

or

base class

extends

Inheritance (contd)

subinterface superinterfaceextends

class interfaceimplements


8/36

UMBC

8

Inheritance (contd)

h In Java,asubclass can extend only onesuperclass.

h In Java,asubinterface can extend onesuperinterface

h In Java,a class can implement several

interfaces this is Javas form ofmultiple inheritance.


9/36

UMBC

9

Inheritance (contd)

h An abstract class can have code forsome of its methods; other methodsaredeclared abstract and left with no code.

h An interface only lists methodsbut doesnot haveany code.

h A

concrete class mayextend anabstract classand/or implement one orseveral interfaces,supplying the codefor all the methods.


10/36

UMBC

10

Inheritance (contd)

h Inheritanceplaysa dual role:

h Asubclass reuses the code from the

superclass.h Asubclass (or a class that implementsan

interface) inherits the data type of thesuperclass (or the interface)as its own

secondary type.


11/36

UMBC

11

Inheritance (contd)

h Inheritance leads to a hierarchy ofclassesand/or interfaces in anapplication:

Game

GameFor2

BoardGame

Chess Backgammon

Solitaire


12/36

UMBC

12

Inheritance (contd)

h Example from Swing:

JComponent

... ... ... JTextComponent

JTextField JTextArea JEditorPane

JPasswordField JTextPane


13/36

UMBC

13

Inheritance (contd)

h An object of a classat thebottom of ahierarchy inheritsall the methods of allthe classesabove.

h It also inherits the data types of all theclassesand interfacesabove.

h Inheritance isalso used to extendhierarchies of library classes, reusingthe library codeand inheriting librarydata types.


14/36

UMBC

14

Inheritance (contd)

h Inheritance implements the isarelationship.

h Not to be confused with embedding (anobject hasanother object asapart),which represents the hasarelationship:

Asailboat isa boat

Asailboat hasa sail


15/36

UMBC

15

Summary (cont)

h Every object isan instance of a class.A classrepresentsa grouping of similar objects.

h The class is the repository of thebehavior

associated with an object. That isall objects thatare instances of thesame class can perform thesameactions

h Classesare organized in asingle rooted tree

structure called the inheritance hierarchy.Memoryand behavior associated with a classareautomaticallyavailable to any class that isadescendant in this inheritance hierarchy


16/36

UMBC

16

Coping with Complexity

h Interconnectedness, the dependence ofoneportion of code on another portion, is

responsible for thisphenomenah Abstraction mechanisms try to copewith

thisand object oriented techniques offeryet another step forward


17/36

UMBC

17

Method Binding andPolymorphism

h When Fred would ask hiswife Beth tosend some flowers to Robin for her

birthdayshe might usea differentmethod than the florist Fred

h The method that getsexecuted inresponse to a message depends on thereceiver of the message. Gettingdifferent methodsexecutes inresponse to thesame message isa

form of polymorphism


18/36

UMBC

18

Sending Messagesvs.Procedure Call

h A message hasa designated receiver (someobject)

h

The interpretation of the message,I

.e. themethod used in response to the message isdetermined by the receiver and can varyamongst different receivers.

h Often theactual receiver of a message is

not known until run-time. There is late ordynamic binding between the messageandthe code fragment (method)used torespond to the message


19/36

UMBC

19

Methodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not Functions

Methodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not Functions

Methodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not FunctionsMethodsare not Functions Methodsare not Functions Methodsare not Functions Methodsare not Functions

Functionsare not Methods


20/36

UMBC

20

Responsibility &Abstraction

h Discussing aproblem in terms of responsibilitiesincreases the level of abstraction and permitsgreater independence between agents

h Theentire collection of responsibilitiesassociated with an object is often described bythe term protocol

h A receiver takes responsibility for responding toa message; thesender of the message need notknow the details of the method used. This isastandard powerful form of abstractionsometimes called information hiding


21/36

UMBC

21

Categoriessurrounding Fred

Material Object

Animal

Mammal

Human

ShopkeeperFlorist Fred


22/36

UMBC

22

Classesand Instances

h Although Chris does not know Fred very he hasarough idea of the transactions that occur insideFredsshop. Chris isable to make certain

assumptionsbased on previousexperienceswithflorists. Heexpects that Fred,being an instanceof the category florist,will match thepattern.

h All objectsare instances of a class. The methodinvoked byan object to respond to a message isdetermined by the class of the receiver.Allobjects of thesame classuse thesame method inresponse to thesame message.


23/36

UMBC

23

A Material Objects ClassHierarchy

Sam

Dog

Fred

Florist

Shopkeeper

Ken

Potter

Artist

Human

Phyl

Platypus

Mammal

Animal

tulip1 tulip2 tulip 3

Tulip

Flower

Plant

Material Object


24/36

UMBC

24

Encapsulation and Instantiation

Classes provide two very important

capabilities:

h Encapsulation - The purposeful hidingof inf ormation, thereby reducing the

amount of details that need to be

remembered/communicated among

programmers.

h Instantiation - The ability to create

multiple instances ofan abstraction.


25/36

UMBC

25

Encapsulation: SeparatingInternal and External Views

Push const limit = 300;

Pop varcurrentTop : 0 .. limit;

Top values : array [ 1 .. limit] of integer;


26/36

UMBC

26

State - Instance Variables

h We havebeen using the term instance tomean a representative or an example of aclass.

h Wewill use the term instance variable torepresent thestate, or data valuesmaintained internal to a class.

h We can record information about theinstance variable on theback side of a CRCcard,since it is internal to a class.

h Clients can see the front of the card,implementers can see thebackside.


27/36

UMBC

27

InterfaceandImplementation

In most OOP languages, the distinction betweeninterface and implementation is manifest on

two

distinct levels:h Within a class, separation between interface

and implementation part Example, in C++,public and private fields.

h

Interface descriptions and implementati

onbodies appearing in separate files (orseparate

area of same file). Example, in C++, *.h filesand *.cpp files.


28/36

UMBC

28

End of Lecture


29/36

UMBC

29

Abstraction

h Abstraction mechanismsare techniques todeal with creating,understanding and

managing complexsystemsh Abstraction is thepurposeful suppression

or hiding of some details of aprocess orartifact in order to bring out more clearlyother aspects, details or structures

h Through abstraction onebuildsa model oftheactual system


30/36

UMBC

30

Abstraction layers in OOP

h At the highest level aprogram is viewed asacommunity of cooperating objects.

h Each object in this communityprovidesservices

h At this highest level the important featuresaretheservicesprovided byeach object and the linesof cooperation and communication between them.

h The next level of abstraction allowsa group ofobjectsworking together to be grouped in aunit

(packages, namespaces,units)allowing some namesto beexposed to theworld outside theunit whileothers remain hidden inside theunit


31/36

UMBC

31

Abstraction layers in OOP

h The next two levels of abstraction dealwith the interaction between 2 individualobjectswhere one (the client)uses

services from the other (theserver)h Theserver advertises theservices it can

provide for the client asan interface, the clientprograms to this interface

h

Theserver providesa concrete implementationfor its interface

h The last level of abstraction considersasingle task in isolation I.e.which stepsimplement asingle method


32/36

UMBC

32

General Forms of Abstraction

abstraction division intoparts

hasa

multiple views

Specialisation

isa

catalogs

repetition

service view

class hierachies ADT

OO pro

grams

patterns

composition

recursive datastructures

recursive algorithms

dictionaries

cross-references


33/36

UMBC

33

Abstraction mechanisms inprogramming languages

h Proceduresand Functions (functioncentered view)+ information hiding for the detail of the

behavior- no information hiding for the detail of the data- no encapsulation

h Modulesand Packages (data centered view)

+ information hiding+ encapsulation- instantiation not alwayssupported

h Abstract Data Types

+ separates interfaceand implementation


34/36

UMBC

34

Abstraction mechanisms in OOprogramming languages

h ClassesareasAbstract Data Types in aservice-centered view

h

MessagePassing andMethodBinding bringpolymorphism leading to more readablecode

h Class HierarchiesandInheritancebringcodesharing which results in increased

functionalityandreduction of codesizeh Inheritanceandpolymorphism together

allow for tailoring sharedcode


35/36

UMBC

35

Object Oriented Design

h Object oriented software development is NOTabout thesyntax of aprogramming language

h Object oriented software development isabout adesign technique driven by the determination anddelegation of responsibilities

h Responsibility implies non-interference, it cuts orreduces the linksbetween objects that depend onimplementation details

h Goesbeyond information hiding and encapsulationwhen dealing with programming in the large


36/36

UMBC

36

References

h Classesand Methods

h OOPIntroduction

h OOP Conceptsh Budd Book

2 1 OOP Introduction

Documents