Previous

Contents

Next

Part Two:
Abstract data types

This part moves the focus from the mechanics of processing data in small examples to the representation of the data being processed. The previous part showed how Ada allows you to define new data types, but it often appears easier to use built-in types provided by the language. In larger-scale applications where maintenance is the dominant cost factor this turns out to be a false economy due to the increased testing and debugging costs incurred after every change. The data types are not faithful representations of the types of object being modelled in the real world, and so it is possible to perform unrealistic actions on them. The more a program is changed, the more likelihood there is of this happening.

Design approaches like stepwise refinement only attack the problem of processing data. Choosing a sensible organisation for the data to make it easier to process is also essential. Top-down design of programs can only work if you have a firm idea of the architecture of the bottom layer that you are trying to reach. It also takes no account of the seismic changes that will result if the nature of this bottom layer changes. This part introduces abstract data types as a way of providing a stable bottom layer towards which a program design can aim, and it shows how a design using abstract data types can be used to contain the impact that maintenance changes in one part of the design will have on other parts.

Previous

Contents

Next

This file is part of Ada 95: The Craft of Object-Oriented Programming by John English.
Copyright © John English 2000. All rights reserved.
Permission is given to redistribute this work for non-profit educational use only, provided that all the constituent files are distributed without change.