Abstraction

ADTs, Information Hiding and Encapsulation

ADT

• ADT = Abstract Data Type– A theoretical concept– A set of (homogeneous) objects together with a

set of operations on those objects– NO mention of how the operations are

implemented– NO rules tell which operations are required

• A design decision

Two Faces of an ADT

• From the outside, the user sees only a collection of operations that together define the behavior of the abstraction

• On the other side, the programmer defining the abstraction sees the data variables that are used to maintain the state

Stack ADT

• The user sees only the description of the legal operations -- push and pop

• The implementer knows the concrete data structure used to implement the abstraction

• The concrete details are encapsulated within a more abstract framework

ADTs (cont’d)

To build an ADT, we must1. Export the type definition

2. Make available a set of operations to manipulate instances of this type

3. Protect the data associated with the type so they can be operated on only by provided operations

4. Make multiple instances of the type

Abstraction

• A mechanism to control complexity– Complexity due to interconnections between software

components. I.e. the dependence of one portion of code on another section of code

• The ability to encapsulate and isolate design and execution information

• Using data abstraction is a methodology wherein information is consciously hidden in a small part of a program

Procedures

• First Abstraction Method– Allowed repeated tasks to be collected in one

place and be reused– Gave possibility for information hiding

• One programmer writes procedure(s)

• Other programmers just need to know interface, not implementation

Characteristics

Behaviors

Function 2

Function 1

Function N

In a procedural application, the characteristics (data) and behaviors (functions) may be in the same file

Characteristics

Or may be in different files. There may be more than one set of data which use the same functions.

Behaviors

Procedural Stack Example

main ( ){ STACK s1; STACK s2;

push (s1, 7); push (s1, 10); push (s2, 5); push (s2, pop(s1));

. ……….

}

void push (STACK s, int i){ // code for push}

int pop (STACK s){ // code for pop}

What’s the Problem?

• The data (STACK variables s1 and s2) are changeable by any line of code in main( )

• The data is “public”

Modules

• A collection of procedures and related data (a .C file) divided into two parts– Public part accessible outside the module– Private part accessible only within the module

Modules (cont’d)

• Popularized by David Parnas– “[A module] must provide the intended user

with all the information needed to use the module correctly, and with nothing more.”

– “[A module] must provide the implementer with all the information needed to complete the module, and nothing more”.

• Like the military “need to know” philosophy

Modules (cont’d)

• Solve some (not all) software development problems

• Ex: Stack module– Stack data private– Stack routines public

main ( )

{

….

}

Private

Characteristics

Public

Behaviors

Main.C Stack.C

Modular Stack Examplemain ( ){ push (7); push (12): push (15);

int x = pop ( );

……….

}

static STACK s;

void push (int i){ // code for push}

int pop ( void ){ // code for pop}

What’s the Problem?

Question:How do you use more than one stack at a time?

Answer:You don’t

ADTs with OOP

• OOP allows us to instantiate multiple instances of each object.

• Each gets its own set of characteristics.

• Conceptually, each gets its own set of behaviors

• This was what procedures and modules couldn’t give us

Objects

• The characteristics and behaviors are encapsulated in a single entity (an object).

• That entity decides which characteristics and which behaviors are publicly available and which remain private.

Encapsulation

• Restricting the effects of change by putting a “wall of code” around the data

• All access to the data is handle by procedures (functions, behaviors) that were put there to mediate access to the data

An OOP ApplicationAn OOP Application

Object Oriented Application Public Behaviors

private

Characteristics

An Object

Message Passing

• OOP extends the concept of ADT by adding the concept of message passing.

• A program requests that an object perform a certain operation.

• Objects can also request that other objects perform operations

A Change of Emphasis

• Do you call the push routine with a stack and a data value

OR

• Do you ask a stack object to push a value onto itself

Inheritance

• Allows different data types to share the same code– Reduced code size– Increased functionality

VEHICLE

Land Vehicle

Car Bicycle Train Boat Submarine Plane Zeppelin

Water Vehicle

Commercial Military Private

Air Vehicle

Procedural “Polymorphism”

Procedural Application

Characteristics

Similar behavior for each representation

OO Polymorphism

OO Application

Single Interface

Similar behavior for each representation