object oriented programing
Post on 14-Dec-2015
44 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
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
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
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
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
top related