Larry Latour brought up the issue of how the process of component generalization is both something we strive for and something that is not trivial. Useful generalizations tend to be the result of modeling good abstractions as targets for uncommitting lower-level design decisions. This modeling process requires an collection of good designer mental models to understand both the starting point and target of the generalization process.
Bruce Weide suggested an interesting generalization of a sort concept to explore these issues. Since mental models can take the form of both abstract concept mental models as in that of a sort concept, to implementation mental models, such as those that support heapsort, we subsequently also looked at implementation mental models and corresponding generalization issues with the implementation of a heapsort.
We began by discussing traditional approaches to generalizing sort by removing many of its external dependencies and premature design decisions [] []. The example then took an unconventional turn as Bruce described the evolution of a single Sort() operation into a Sorting_Machine ADT with its accompanying primary operations. This step in the example was based on work done in recasting large-effect operations into objects with a number of small-effect operations [].
Figure 
is an elaboration of one of the working
group's simplified white board figures.
A sorting machine is modeled as a machine that has
separate insertion and extraction phases, with operations for
performing insertion and extraction, and for switching between phases.
This approach to generalizing a single Sort() operation
admits any possible implementation of sorting, but also gives
the implementer more freedom to distribute the costs among the
(many) small-effect operations in ways that are beneficial to clients
with different calling patterns [].
The sorting machine example nicely captured several concerns about
generalizing components and designing their interfaces, while
simultaneously illustrating many of the concerns about designing
components with good mental models.
The idea of a sorting machine was fairly interesting, and in retrospect should be able to be applied to any complex algorthm that can be broken down into a series of abstract steps. The issue seems to be one of how much control is needed in using the algorithm within a context. This in turn raises the related issue of how the functionality of an abstract data type is partitioned. A specific example is the Unix philosophy of providing a large set of simple, orthogonal operations, as opposed to a smaller set of more context sensitive operations. Specifically, it seems that the pipe combinator was designed in such a way as to facilitate rapid prototyping of communications protocols and other domain specific filters at Bell Labs. Certainly there is more flexibility using the operations separately, although there are a small, standard number of ways of combining them that are used by "knowing" software designers.
While the sort generalization exercise was progressing, a concern was raised to try to state precisely the assumptions and implications of each of the generalizations. Most of the vocal attendees seemed conversant with data structures and had experience teaching, using, and reasoning about them. They seemed to be comfortable with the reasons behind at least the simply parametric generalizations, and didn't see the need to write the reasons for generalizing them down. This, some of us noted, tended to be true in general of computer science domain people.
