When things go right, changing a data structure in a slow program works the same way an organ transplant does in a sick patient. For several classes of abstract data types, such as containers, dictionaries, and priority queues, there exist many different but functionally equivalent data structures that implement the given data type. Changing the data structure does not change the correctness of the program, since we presumably replace a correct implementation with a different correct implementation. However, because the new implementation of the data type realizes different tradeoffs in the time to execute various operations, the total performance of an application can improve dramatically. Like a patient in need of a transplant, only one part might need to be replaced in order to fix the problem.
It is obviously better to be born with a good heart than have to wait for a replacement. Similarly, the maximum benefit from good data structures results from designing your program around them in the first place. Still, it is important to build your programs so that alternative implementations can be tried. This involves separating the internals of the data structure (be it a tree, a hash table, or a sorted array) from its interface (operations like search, insert, delete). Such data abstraction is an important part of producing clean, readable, and modifiable programs. We will not dwell on such software engineering issues here, but such a design is critical if you are to experiment with the impact of different implementations on performance.
In this chapter we will also discuss sorting,
stressing how sorting
can be applied to solve other problems more than the details of specific
sorting algorithms.
In this sense, sorting behaves more like a data structure than a problem
in its own right.
Sorting is also represented by a significant entry
in the problem catalog; namely Section 
.
The key take-home lessons of this chapter are: