object oriented programing

Published on June 2017 | Categories: Documents | Downloads: 22 | Comments: 0 | Views: 121
of 40
Download PDF   Embed   Report



‫עזאם מרעי‬
‫המחלקה למדעי המחשב‬
‫אוניברסיטת בן‪-‬גוריון‬


Tools for Programming
Complex Software

Fundamentally, people use only a few simple tools
to create, understand, or manage
complex systems
One of the most important techniques is termed



 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 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


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


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.


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
Package “Data


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


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.

Joe’s Data Structure Warehouse
Services offered:
void push(Object val);
Object top();
void pop();


Levels of Abstraction in OO -Interfaces


Interfaces are one way to describe services at
this level of abstraction:

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:
public class LinkedList implements Stack ... {
public void pop () throws EmptyStackException {

Concern here is with the high level approach to
providing the designated service


Levels of Abstraction -- A Method
in Isolation
Finally, we consider the implementation of each
method in isolation:
public class LinkedList implements Stack ... {
public void pop () throws EmptyStackException {
if (isEmpty())
throw new EmptyStackException();
removeFirst(); // delete first element of list



Levels of Abstraction

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



Forms of Abstraction
Division into parts

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


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


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


 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


Encapsulation and
 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


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.
Joe’s Data Structure Warehouse
Services offered:
void push(Object val);
Object top();
void pop();



A measure for dependency:
 Coupling is the amount of dependency among

 A system with many dependencies has high

 Good systems have low coupling

 Low coupling is a major pattern (advice) in

assigning responsibilities to modules.


Degree of Coupling
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


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


Composition in the Creation of
User Interfaces

Example of Composition –
Regular Expressions


(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


A Short History of Abstraction
Another way to better understand OOP is to put it in
context with the history of abstraction in computer

Assembly languages








The Service View



vii. The future....


ENIAC – The First Electronic


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


 Symbolic names for operations
 Linking of names and locations performed automatically


10110000 01100001


B0 61


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
 But they are not an entirely effective mechanism

of information hiding


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

Where can you hide the implementation?



 Modules basically provided

collections of procedures and data
 With import and export statements
 Solves the problem of encapsulation


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


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
 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


Three Eons of History
Looking at this history, we can separate it into
three periods of time:

Functionality of
the application

Data types used in
an application

services provided
by objects in the


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


OMG one picture MDA

Core Target



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

Sponsor Documents

Or use your account on DocShare.tips


Forgot your password?

Or register your new account on DocShare.tips


Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in