An Object-Oriented Design

Our implementations of min() and max() make no special assumptions about the storage of the
array elements and therefore require that we examine each element. Had we required the elements to
be sorted, the implementation of both operations would become a simple index into, respectively, the
first and last element. Moreover, a search for the presence of an element is considerably more
efficient if the elements are known to be sorted. Supporting the elements in sorted order, however,
adds to the complexity of the Array class implementation. Have we made a mistake in our design?
We haven't made a mistake so much as we've made a choice. A sorted array is a specialized
implementation: when it is necessary, it is absolutely necessary; otherwise, the overhead of its
support is a burden. Our implementation is more general and, in most circumstances, adequate; it
supports a wider range of users. Unfortunately, if the user absolutely needs the behavior of a sorted
array, our implementation cannot support that. There is no way for the user to override the more
general implementations of min(), max(), and find(). In effect, we have chosen a generally useful
implementation that is inappropriate under special circumstances.
On the other hand, for another category of user our implementation is too specialized: rangechecking
of the index adds overhead to each access of an element. We discounted the cost of this in
our design (see item 8 in Section 2.3) with the assumption that being fast is of little value if we are
incorrect. This assumption, however, does not hold true for at least one of our major users: a realtime
virtual-immersion or virtualreality provider. The arrays, in this case, represent shared vertices of
complex 3D geometry. The scene flies by too quickly for an occasional error to be generally visible,
but if the general access is too slow, the immersion effect breaks down. Our implementation,
although considerably safer than a non-range-checking array class, is impractical for this application
domain.
How might we support the needs of these three sets of users? The solutions are already present in the
code, more or less. For example, our range-checking is localized within the subscript operator.
Remove the invocation of check_range(), rename the array, and we now have two
implementations: one with and one without range-checking. Copy more of the code, modify it to
treat the array as sorted, and we now have support for a sorted array:
// Unsorted, with no bounds-checking
class IntArray{ ... };
// Unsorted, with bounds-checking
class IntArrayRC{ ... };
// Sorted, without bounds-checking
class IntSortedArray{ ... };
What are the drawbacks with this solution?