Object Oriented Programming - PowerPoint PPT Presentation

1 / 38
About This Presentation
Title:

Object Oriented Programming

Description:

Abstraction considerations can be broken down into design-time and compile-time. Compile-time ... Regular Expressions - A pattern of characters used to match ... – PowerPoint PPT presentation

Number of Views:54
Avg rating:3.0/5.0
Slides: 39
Provided by: JA
Category:

less

Transcript and Presenter's Notes

Title: Object Oriented Programming


1
Object Oriented Programming Design -
AbstractionLecture 2
  • John Anthony
  • RPI - Adjunct Assistant Professor
  • Department of Engineering and Science

2
Topics
  • What is Abstraction
  • The Lientz Study
  • Examples of Abstraction
  • Layered View of an Object Oriented Program
  • Other Forms of Abstraction
  • Introduction to Abstract Data Types

3
Abstraction
The most effective weapon that computing
scientists have in their fight against complexity
is abstraction. What is abstraction?
  • A simplified description or view of something
    that emphasizes characteristics or purposes
    relevant to the user, while suppressing details
    that are immaterial or distracting.
  • Translated focus on the what not the how.

http//www.inf.ufsc.br/poo/smalltalk/ibm/tutorial/
glossary.html
4
Remember Information Hiding?
  • Certain details can and in many cases should
    remain hidden from the client
  • Why is this????

5
Part of the Answer
Bennet P. Lientz and E. Burton Swanson Software
Maintenance Management a Study of the
Maintenance of Computer Application Software in
487 Data Processing Organizations,
Addison-Wesley., Readinhg (Mass.), 1980.
6
Examples of Abstraction
  • Abstracts of a research papers
  • Maps
  • Virtual Memory
  • The relationship between a registrant for a Race
    and the Register (Active).
  • Java.lang.String (vs. array of bytes)
  • etc.

7
Layered View of an Object Oriented Program
Service
1
n
Program
1
Decreasing levels of abstraction
n
Packages
1
n
Classes
1
n
Operations
8
Layered View - Services
Service (Service Oriented Architecture)
Service
  • Services provide network addressable, loosely
    coupled, and stateless operations to consumers.
  • Network Addressable bound to a network address
    (URI) and (often) published to a registry for
    discovery.
  • Loosely Coupled services exchange data and are
    invoked using non-proprietary technologies.
    Services can also be composed into other
    services.
  • Stateless the execution of a Service N does not
    depend on the execution of Service N-1 or Service
    N1.

1
n
Program
1
Decreasing levels of abstraction
n
Packages
1
n
Classes
1
n
Operations
9
Layered View - Programs
Program
Service
  • An object oriented program is a community of
    objects that interact in order to achieve a
    common goal. A program is the implementation of a
    service.
  • Community of Objects The interface of a program
    hides the complexity of the underlying number,
    types, and relationships between the objects.
    Application Programming Interface (API) User
    Interface
  • Common Goal the program and its underlying
    model should solve a problem or set of like
    problems.

1
n
Program
1
Decreasing levels of abstraction
n
Packages
1
n
Classes
1
n
Operations
10
Layered View - Packages
Packages
Service
Some OOP languages support the grouping of
classes into packages. Packages provide a
(logical) grouping of classes while providing
mechanisms for certain classes and features to be
package public and package private.
1
n
Program
1
Decreasing levels of abstraction
n
Packages
1
n
Client
Classes
Package x
1
Class A
Class B
n
Operations
Class C
11
Layered View - Classes
Classes
Service
A class is a static representation of the data
and behavior of a set of objects. The public
interface of a class serves as a contract to the
supplier. The interface should abstract the
internal implementation details of the supplier
from the client. Consider public,
friendly Note Java supports the notion of
inner and anonymous classes which provides yet
another level of abstraction at the class level.
1
n
Program
1
Decreasing levels of abstraction
n
Packages
1
n
Classes
1
n
Operations
Client
Supplier
Class A
Class B
12
Layered View - Operations
Operations
Service
  • The class level is concerned with what parts of
    the interface should be exported or made public.
  • Abstraction considerations can be broken down
    into design-time and compile-time.
  • Compile-time
  • Access modifier (public, protected, private,
    friendly)
  • Design-time
  • Operation Name
  • Operation Parameters
  • Return Values (also know as functions)

1
n
Program
1
Decreasing levels of abstraction
n
Packages
1
n
Classes
1
n
Operations
Client
Supplier
Class A
Class B
13
Other Forms of Abstraction
14
Encapsulation Composition
  • Encapsulation - A technique for hiding
    information within a structure.
  • Composition A technique for building complex
    structures out of simpler parts. These
    techniques not only provides abstraction, it also
    supports interchangeability.

Redesigned And Gate
Memory
Control Unit
Decoder
Not Gate
Computer
CPU
ALU
Full Adder
And Gate
Bus
Registers
Logical Unit
OR Gate
higher levels of abstraction
15
Composition Example
  • Regular Expressions - A pattern of characters
    used to match against the same characters in a
    search. They usually include special characters,
    which represent things other than themselves, to
    refine the search.
  • Text Regular Expression Result
  • Catastrophic cat cat (0,3)
  • Catastrophic cat. cata(0.4)
  • Catastrophic cbzat cat(0,3)
  • Catastrophic6 (a-z5\b) no match

16
Composition Example 2
  • Consider building a GUI in Java.

Insert picture of GUI and highlight composition
17
Encapsulation Composition (cont)
Encapsulation
Composition
Public Part
Secret Part
18
Inheritance
  • The property of objects by which instances of a
    class can have access to data and method
    definitions contained in a previously defined
    class (the ancestor), without the definitions
    being restated.
  • When designing a CPU, youd like to be able to
    swap in and out different scheduling algorithms
    without having to build in special considerations
    into the CPU.

Partial implementation
Scheduler
Operating System
higher levels of specialization
higher levels of abstraction
FCFS
SJF
RR
19
Composition vs. Inheritance
  • How do we know when to use which strategy?
  • Apply the is-a and the has-a test.

20
Interfaces
  • Interfaces can be separated from the
    implementation.
  • The interface describes the what and the
    implementation describes the how.

Interface
Implementation
public interface Stack public void put(Object
o) public Object top()
public class ListStack implements Stack public
void put(Object o) list.add(o)
21
Cohesion and Coupling
  • Cohesion the degree to which components of a
    single software system (such as members of a
    single class) are tied together.
  • Coupling the degree to which separate software
    components are tied together.
  • Design goal Systems (objects) should be highly
    cohesive and loosely coupled.

22
Poor Cohesion
public abstract class Policy private List
drivers . / _at_return Returns the
drivers. / public List getDrivers()
return drivers / _at_param drivers
The drivers to set. / public void
setDrivers(List drivers) this.drivers
drivers .
23
History of Abstraction Mechanisms
Assembly Language
opcode
Operand1
Operand2
33 372 376 35 377 376
integer addition
integer subtraction
memory locations
24
Assembly Language (with Assembler)
Command
var1, var2
ADDI A, X SUBI B, X
integer addition
integer subtraction
pointers
25
Procedures Functions
  • First mechanism for reuse and information hiding.
    However, there were still problems

. boolean locked false void lock()
locked true void unlock() locked
false .
26
Modules
  • Modules - divided the name space into public and
    private areas.

Dr. David Parnas father of modular
design. "...it is almost always incorrect to
begin the decomposition of a system into modules
on the basis of a flowchart. We propose instead
that one begins with a list of difficult design
decisions or design decisions which are likely to
change. Each module is then designed to hide such
a decision from the others."
. private boolean locked false public void
lock() locked true public void unlock()
locked false .
27
Abstract Data Types
An Abstract Data Type (ADT) is an abstract
specification that defines the data types and
operations independent of the implementation.
  • The notion of an ADT was driven by two important
    goals
  • The need to define new data types (beyond the
    primitives supported by the language).
  • The need to use the features of an ADT without
    being exposed to the underlying implementation.

28
Abstract Data Types (cont)
  • Every ADT must contain 4 paragraphs
  • Types
  • Functions
  • Axioms
  • Preconditions

29
The Stack ADT
  • The Stack class represents a last-in-first-out
    (LIFO) stack of objects. It extends class Vector
    with five operations that allow a vector to be
    treated as a stack. The usual push and pop
    operations are provided, as well as a method to
    peek at the top item on the stack, a method to
    test for whether the stack is empty, and a method
    to search the stack for an item and discover how
    far it is from the top.

30
Types
  • The types paragraph lists the types introduced
    into the specification.

Types
Stack Object
This specification is about a single abstract
data type Stack, describing stacks of objects of
type Object.
31
Functions
  • The functions paragraph lists the operations
    applicable to instances of the ADT.

Functions
push StackObject ? Object pop StackObject ?
Object peek StackObject ? Object empty
StackObject ? boolean
32
Functions (cont)
  • The functions paragraph described the signatures
    of the functions but it did not define the
    functions. As such, we do not have a Stack
    (LIFO) yet.

33
Axiomatic Definitions
  • Each axiom must hold for all instances s of type
    Stack and all elements x of type Object.

A1 tells us that the top element of the stack
is the last element pushed
Axioms
For any xObject, sStackObject, A1 peek
(push (x) ) x A2 pop (push (x) ) s A3
empty (new) A4 not empty (push(s, x))
A2 tells us that removal of the top element
returns the stack to the state it had before the
last push
A3 tells us that a newly created stack is empty
A4 tells us that pushing an entity on a stack
results in a nonempty stack
34
???
  • Are we satisfied with our specification?

35
Preconditions
  • Since ADTs may contain partial functions,
    preconditions are stated in order to avoid errors.

The precondition of an operation is a logical
assertion that specifies the assumptions about
and the restrictions upon the values of the
arguments of the operation.
If the precondition of an operation is false,
then the operation cannot be safely applied. If
any operation is called with its precondition
false, then the program is incorrect.
36
Preconditions (cont)
Preconditions
pop (s Stack Object) required not empty (s)
peak (s Stack Object) required not empty (s)
37
Complete ADT Specification of Stacks
Types
Stack Object
Functions
push StackObject ? Object pop StackObject ?
Object peek StackObject ? Object empty
StackObject ? boolean
Axioms
For any xObject, sStackObject, A1 peek
(push (x) ) x A2 pop (push (x) ) s A3
empty (new) A4 not empty (push(s, x))
Preconditions
pop (s Stack Object) required not empty (s)
peak (s Stack Object) required not empty (s)
38
Implementing an ADT
Types, Functions, Axioms, and Preconditions
Public Part ADT Specification
Secret Part choice of representation implementa
tion of functions
Vector
public Object pop() Object x null
if(! empty()) x
this.firstElement this.removeElementA
t(0) else return x
Write a Comment
User Comments (0)
About PowerShow.com