Instructor's Manual for
M.B. Feldman and E.B. Koffman, Ada 95 Problem Solving and Program Design, 3rd edition. Copyright 1999, Addison-Wesley Publishing Company. All Rights Reserved.
Questions and comments to mfeldman@seas.gwu.edu.
last revised March 1999
The student will
|
abstract data type (ADT) |
client program |
|
infirmation hiding |
representation |
|
constructor |
selector |
|
inquiry operation |
reusable software component |
|
time |
elapsed time |
|
PRIVATE type |
package-defined exception |
|
RAISE statement |
This chapter focuses on data abstraction and the Ada package. In discussing the general nature of abstract data types (ADTs), point out that while Ada package facility was designed to support ADTs well, the ADT concept was developed in the research community well before Ada, and that nearly every language developed since the 1970s has included some support for ADTs.
Object-oriented programming, a generalization of ADTs, was not supported in Ada 83 because Ada's designers were unsure whether OOP could be implemented efficiently. Inheritance, an important aspect of OOP, is supported more fully in Ada 95, and is covered in Chapter 16.
Discuss information hiding with your students. Point out that much of their programming thus far has hidden details from them; the complexity of device-level input/output is a good example. We do information hiding not because we do not trust programmers--after all, they can often look at the source code or other details of packages they are using--but in order to reduce complexity by reducing the detail at each level.
You might prepare your students for private types by discussing the question of "guarantees" for software. If we provide a package to other programmers, we should be in a position to guarantee the integrity of its operations, and therefore we need to prevent client programs--not the programmers, but the programs--from "breaking" our package. Remind the students of the importance of preconditions and postconditions in the "contract" between the package writer and the package user.
Your students might ask whether package Standard is available to them in machine-readable form. Your response should be that Standard is "built-in" to Ada and the package-like specification is just a way of describing the facilities in it.
This is a good chance to explore your students' concept of time with them, pointing out the difference between time of day and elapsed time, and discussing why there is no operator in Ada.Calendar that adds two Time values. Ada.Calendar serves as an excellent introduction to the private type concept: making a type PRIVATE abolishes all operations but assignment and equality test, and therefore gives the programmer complete control over what can be done with values of the type. There are no arithmetic operations on Time values except those that common sense shows to be appropriate.
Explain the value in exporting the exception Time_Error in guaranteeing the integrity of a Time value: a client program cannot successfully create a value representing February 30, or February 29 in a non-leap year.
Unlike the Simple_Dates package in Chapter 9, this Dates package is robust: an invalid date cannot be created. Emphasize that only Date_Of constructs a date; it is used even by Dates.IO.Get. Show how Date_Of validates its inputs by calling Ada.Calendar.Time_Of; point out that because Date is a private type, a client cannot subvert the integrity of a date by doing an explicit assignment to a field. A secondary but useful reason for making the type private is that we could change the internal structure of a Date value without forcing any client code to be changed. Only a recompilation would be necessary.
An interesting project might be to improve Dates.IO so that the interactive is robust in the sense of the robust input package of Chapter 7.
The Currency package is very similar in flavor to the Dates one. Discuss with your students why we should need a separate representation for currency, that is, why Float is not acceptable. Also discuss the reasons why certain operations are present and absent.
This section shows that ADTs are not just for mathematical types, but can be used for database-like appplications. Indeed, the programmer's interface to a DBMS is really a scaled-up version of this example.
The employee inquiry system is left incomplete, so that it can be used as a capstone project in a course that covers only Chapters 1-11. There is enough richness in the project that nearly every important concept in those chapters is called into play. All the pieces are provided in compilable, execitable form, but certain operations are stubbed out, for completion by the student. I have used this and similar projects with success in my introductory course; most students "get" most of it.
This section introduces a modification of the spider package, transforming it from an abstract data object (ADO) to an ADT. This allows several spiders to coexist in the room. The body of the package is not given, so you can assign its completion--a modification of Program 8.9--as a project.