Java Templates

Java templates are promised for summer 2004 in Java 1.5.0. You can search for them on the web and on the Sun web site. I'm tracking some of these changes on my [ java.html ] web page.

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://csci.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

• 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).
implementor: I don;'t worry about how you use my function as long as
• 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).

. . . . . . . . . ( end of section Supplement) <<Contents | End>>