.Open CS320/14 Data Abstraction
.Table
.Row Prev 13	Functional Programming	Chapter 15 not section 8       lab13 LISP103
.Row 14 	Data  Abstraction       Chapter 2 section 14 + Chapter 11	lab14 C/C++ ADTs
.Row Next **	Project Deadline Phase 2        Phase 2 due in: changed EBNF and draft UML (10pts)
.Row Next 15	OO  Programming and Java        Chapter 2 section 17 + Java Handout +  Chapter 12  	lab15 Java101
.Close.Table
. Preparation
	Study Chapter 2 Setction 14 on Ada.
  Study the $Supplement below
  Study Chapter 11 on Data Abstraction
  Answer the review questions at the end of chapter 11.
  Hand in 2 questions.
.Open Supplement
. The Stack ADT
.See http://www/dick/cs320/stacks
. Ada
The complete definition of Ada 83 -- the Language Reference Manual ( LRM) 
is on file at
.See http://www/dick/cs320/ada/lrm
There are many samples of Ada code in
.See http://www/dick/cs320/ada/
The Gnu C++ and C compiler suite includes Gnat compiler for Ada -- but I 
don't think we have implemented it, yet. There is a compiler for Ada that 
produces WWW Applets. I have a CDROM advert for it.
. Interface, Implementation, Abstract, Concrete
I will use the term 
.Key interface
for a completely abstract description of a 
data type with all implementation details hidden. This means an API 
(Application Programmer `Interface`). In essence an $interface is a list of 
function prototypes or subprogram protocols. It states the operations that
can be invoked. An interface is an inter-face: a layer separating two 
components. One side of an interface is the implementation. On the other 
side are the pieces of code (clients) that make use of the interface. never
forget that there are two sides to every interface: provider and requirer.

Notice that if an object is in a class that implements an interface then 
the compiler can make sure that all the operations applied to the object 
are in the interface. The actual class of the object does not matter.... 
all that matters is that the object's class fits the interface. This is 
like a modular phone jack!

There are many ways to implement the same interface. Each implementation 
completes the function/operation/subprogram definitions in a special way.

An 
.Key abstraction
has some details hidden (to-be-announced) and some defined.

An 
.Key abstract
subprogram, function, or operation has no body. An 
.Key abstract class
has a mixture of defined functions, abstract functions, and 
variables. 

There are many ways to 
.Key implement
(completely define) an 
abstraction. The defined parts provide a framework. The undefined parts are
places to plug in specific pieces of code into the framework. An example 
would be a class that defines a 'sort' function but does not define a 
function that tests if two objects are in order. By supplying the 
definition of this function you can plug-in your own sort order.

A 
.Key concrete module
has all its details defined. There is enough information
available for objects of a concrete class to be constructed. As a result 
you can do any of the defined operations with objects that have a concrete
type.

. Abstraction and Interfaces in C++
.See ./14interfaces.cpp

. Abstraction and Interfaces in the UML
UML has several notations concerned with data abstraction. It defines the 
stereotype <<interface>> and the constraint {abstract}.

A dotted or dashed
open arrow joins an implementation to its abstractions. A closed dotted 
arrow shows that a class uses an interface to access an implementation. 
There is a special "lollipop" notation indicating a piece of code that 
implements an interface. Or you can add <<interface>> as a stereotype to a
class box.

.Image 14/ole2.gif Interfaces in UML

In UML 2.0 the arrow and lollipop notation has become a "cup-and-ball"
notation.

Here is an example, in Java we may want to create a class that is an Applet
in a web page, and also reacts to what the user does with mouse, and is 
also multithreaded. The diagram shows the Java Virtual Machine using our 
class via two interfaces:

.Image 14/ole3.gif ThreadMouseListener is an Applet that is threaded and listens for mouse events

. Describing Interfaces
An interface is a collection of functions, operations, and perhaps 
constants. Many just use their favorite syntax for
classes. It is harder to express the meaning of the
operations. The best technique is to describe a set of contract that holds
between the client of the interface and its implementor. Contracts have 
pre-conditions and post-conditions.

Client programmer: I don't worry about how you code it as long as
.Set 
 I guarantee the pre-conditions will be true when I call this function.
		   (so you don't have to test them).
 I assume that the post-conditions will be true after it finishes.
		   (so I don't have to test them).
.Close.Set
Implementor: I don't worry about how you use my function as long as
.Set
 I assume that the preconditions will be true 
when the function is called.
		   (I don't have to test them).
 I guarantee that the post-conditions will be 
true just before I return control.
		   (so you don't have to test 
them).
.Close.Set

.Close Supplement
.Close
. Class Work
.See ./14q.html
. Lab Work -- Spot the ADT
.See ./lab/14.html
. Next -- OO and Java
.See ./15.html