object oriented programing

מרעי עזאם

המחלקה למדעי המחשב

גוריון-אוניברסיטת בן

Abstraction

Tools for Programming Complex Software

2

Fundamentally, people use only a few simple tools

to create, understand, or manage

complex systems

One of the most important techniques is termed abstraction.

Roadmap 3

In this chapter we will consider abstraction,

which is the most important tool used in

the control of complexity

We will examine various

abstraction mechanisms

We will present a short

history of the development of

abstraction tools

?

Abstraction 4

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 structure

Information Hiding

Purposeful omission of details in the

development of an abstract representation

Information hiding is what allows

abstraction to control complexity

5

Abstraction in an Atlas

Think of an atlas, and the various different levels of maps:

A map of the world, contains mountain ranges, large political boundaries

A map of a continent, contains all political boundaries, large cities

A map of a country, contains more cities, major roads

A map of a large city, roads, major structures

A map of a portion of a city, buildings, occupants

6

Levels of Abstraction in

Object Oriented Programs

At the highest level of abstraction we view a program as a community of interacting objects (and interacting programmers).

Important characteristics here are the lines of communication between the various agents.

7

Abstraction in OO Programs --

Packages and Name spaces

The next level of abstraction is found in some (but not all)

object oriented languages

A package, Unit or Name Space allows a programmer to

surround a collection of objects (a small community in itself)

with a layer,

And control visibility from outside the module

8

Package “Data

Structures”

Abstraction in OO Languages --

Clients and Servers

The next two levels of abstraction considers the

relationship between two individual objects

Typically one is providing a service, and the other

is using the service

Two layers of abstraction:

view from the client side / view from the server side

9

Client Server

Abstraction in OO languages --

Description of Services

In a good object-oriented design we can describe the services

that the server provides without reference to actions that the

client may perform in using those services

We define the nature of the services that are offered, but not

how those services are realized.

10

Joe’s Data Structure Warehouse

Services offered:

void push(Object val); $2.00

Object top(); $1.00

void pop(); $0.75

Levels of Abstraction in OO --

Interfaces

Interfaces are one way to describe services at

this level of abstraction:

11

interface Stack {

public void push (Object val);

public Object top () throws EmptyStackException;

public void pop () throws EmptyStackException;

}

Levels of Abstraction –

An Implementation

Next we look at the same boundary, but from the

server side:

Concern here is with the high level approach to

providing the designated service

12

public class LinkedList implements Stack ... {

public void pop () throws EmptyStackException {

...

}

...

}

Levels of Abstraction -- A Method

in Isolation

Finally, we consider the implementation of each

method in isolation:

13

public class LinkedList implements Stack ... {

...

public void pop () throws EmptyStackException {

if (isEmpty())

throw new EmptyStackException();

removeFirst(); // delete first element of list

}

...

}

Summary:

Levels of Abstraction

14

Interface

Implementation

Strategy

Methods

Every level is important, and often

we move quickly back and forth between levels

The name of the game:

Finding the right level of abstraction

To determine what details are appropriate at each

level of abstraction,

And, more importantly, what details should be omitted

One does not want to ignore or

throw away important information

But one does not want to

manage too much information,

Or have the amount of information hide critical details

15

Forms of Abstraction 16

Abs

trac

tion

Division into parts

Specialization

Multiple views

Is-a and Has-A abstraction

Two of the most important types of abstraction are the following:

Division into parts -- Has-a abstraction

Division into specialization -- Is-a abstraction

Both is-a and has-a abstractions will reappear in later chapters and be tied to specific programming language features

17

Has-A Abstraction

Division into parts takes a complex system, and divides into component parts, which can then be considered in isolation.

Characterized by sentences that have the words “has-a”:

A car has-an engine, and has-a transmission

A bicycle has-a wheel

A window has-a menu bar

Allows us to drop down a level of complexity when we consider the component in isolation

18

Is-a Abstraction

Is-a abstraction takes a complex system, and views it as an instance of a more general class

Characterized by sentences that have the words “is a”:

A car is a wheeled vehicle, which is-a means of transportation

A bicycle is a wheeled vehicle

A packhorse is a means of transportation

Allows us to categorize artifacts and information and make it applicable to many different situations

19

Encapsulation and

Interchangeability

An important aspect of division into parts is to

clearly characterize the connection, or

interface, between to components

Allows for considering multiple

different implementations of the same interface

For example, a car can have several different

types of engine and one transmission

20

The Service View

Another way to think of an interface is as a way

of describing the service that an object provides

The interface is a contract for the service

If the interface is upheld, then the service will be

provided as described.

21

Joe’s Data Structure Warehouse

Services offered:

void push(Object val); $2.00

Object top(); $1.00

void pop(); $0.75

A measure for dependency:

Coupling

23

Coupling is the amount of dependency among

modules.

A system with many dependencies has high

coupling.

Good systems have low coupling

Low coupling is a major pattern (advice) in

assigning responsibilities to modules.

Degree of Coupling 24

The degree of coupling between two components can be

qualitatively measured by determining the effects of changing

the contract or interface between two components or systems.

For example:

What would happen if you added or deleted a property from a class?

What would happen if you changed the data type of a column in a table?

What would happen if you added a column to a table?

What would happen if your database server changed from SQL Server to

mySQL or Oracle?

The degree of pain that each of these changes would cause you

is a good qualitative measurement of how tightly coupled your

components are to the components they depend on

Other Types of Abstraction --

Composition

While is-a and has-a are two important types of abstraction, there are others

Composition is one example; a form of has-a; characterized by the following:

Primitive forms

Rules for combining old values to create new values

The idea that new values can also be subject to further combination

Examples include regular expressions, type systems, windows, lots of other complex systems

25

Composition in the Creation of

User Interfaces

26

Example of Composition –

Regular Expressions

27

(empty set) ∅ denoting the empty set.

(empty string) 𝜀 denoting the set containing only the "empty" string, which has no

characters at all.

(literal character) 𝑎 in Σ denoting the set containing only the character 𝑎.

(concatenation) 𝑅𝑆 denoting the set { 𝛼𝛽 | 𝛼 in 𝑅 and 𝛽 in 𝑆 }. For example {𝑎𝑏, 𝑐}{𝑑, 𝑒𝑓} = {𝑎𝑏𝑑, 𝑎𝑏𝑒𝑓, 𝑐𝑑, 𝑐𝑒𝑓}.

(alternation) 𝑅 | 𝑆 denoting the set union of 𝑅 and 𝑆.

For example {𝑎𝑏, 𝑐}| 𝑎𝑏, 𝑑, 𝑒𝑓 = {𝑎𝑏, 𝑐, 𝑑, 𝑒𝑓}.

(Kleene star) 𝑅∗ denoting the smallest superset of 𝑅 that contains 𝜀 and is closed

under string concatenation.

This is the set of all strings that can be made by concatenating any finite number

(including zero) of strings from 𝑅.

For example, 0,1 ∗ is the set of all finite binary strings (including the empty string),

and 𝑎𝑏, 𝑐 ∗ = {𝜀, 𝑎𝑏, 𝑐, 𝑎𝑏𝑎𝑏, 𝑎𝑏𝑐, 𝑐𝑎𝑏, 𝑐𝑐, 𝑎𝑏𝑎𝑏𝑎𝑏, 𝑎𝑏𝑐𝑎𝑏, … }.

Design Patterns

Patterns are another attempt to document and reuse abstractions

Patterns are description of proven and useful relationships between objects; which can help guide the solution of new problems

Example pattern, Proxy:

We’ll have many more patterns in a later chapter

28

Client Proxy Server

A Short History of Abstraction

Mechanisms

Another way to better understand OOP is to put it in context with the history of abstraction in computer science:

i. Assembly languages

ii. Procedures

iii. Modules

iv. ADT

v. The Service View

vi. Objects

vii. The future....

29

ENIAC – The First Electronic Computer

30

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

31

Binary 10110000 01100001

Hexa. B0 61

ASM MOV AL, 61h ; Load AL with 97 decimal (61 hex)

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

32

Information Hiding –

The Problem of Stacks

Where can you hide the implementation?

33

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]; else return 0; } int pop() // pop element from the stack { if (datatop > 0) return datastack [--datatop]; else return 0; }

Modules

Modules basically provided

collections of procedures and data

With import and export statements

Solves the problem of encapsulation

34

Parnas's Principles

David Parnas described two principles for the

proper use of modules:

One must provide the intended user of a module

with all the information needed to use the module

correctly, and with nothing more

One must provide the implementer of a

module with all the information needed to

complete the module, and nothing more

35

36

What if we need more than one stack?

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

Must have the ability to instantiate many different copies of the data type

Data type can be manipulated using provided operations, without knowledge of internal representation

ADTs were important not because they were data structures, but because they provided an easily characterized service to the rest of an application

37

Three Eons of History

Looking at this history, we can separate it into

three periods of time:

38

Functionality of the application

Data types used in an application

services provided by objects in the

application

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

Classes -- a way of organization that permits

sharing and reuse

Polymorphism -- A new form of software reuse

using dynamic binding

39

OMG one picture MDA

Software Engineering, 2012 Design by Contract

40

Core

Technologies

Core Target

Platforms

Pervasive

Services

Vertical

Domains

What Does the Future Hold

What will be the next evolutionary step in software?

Prediction is hard, particularly about the future

However, once you have accepted the idea of an application formed from interacting agents:

There is no reason why those components must exist on the same computer (distributed computing)

Or be written in the same language (components)

So some of the trends we see today in software are natural results of the OOP mind set

41