CS320/14 Data Abstraction
- 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.
Supplement
- 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).
- 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).
The Stack ADT
[ stacks ]Ada
The complete definition of Ada 83 -- the Language Reference Manual ( LRM) is on file at [ lrm ] There are many samples of Ada code in [ http://cse.csusb.edu/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 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 abstraction has some details hidden (to-be-announced) and some defined.
An abstract subprogram, function, or operation has no body. An abstract class has a mixture of defined functions, abstract functions, and variables.
There are many ways to 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 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++
[ 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.
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:
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
. . . . . . . . . ( end of section Supplement) <<Contents | End>>
Table
| Prev 13 | Functional Programming | Chapter 15 not section 8 | lab13 LISP103 |
| 14 | Data Abstraction | Chapter 2 section 14 + Chapter 11 | lab14 C/C++ ADTs |
| Next ** | Project Deadline Phase 2 | Phase 2 due in: changed EBNF and draft UML (10pts) | |
| Next 15 | OO Programming and Java | Chapter 2 section 17 + Java Handout + Chapter 12 | lab15 Java101 |
(Close Table)