Now with these classes as examples, let us return to the issue of designing a class to be extended. We
carefully designed the protected interface of SortDouble to allow extended classes more intimate access to
the data in the object but only to things we want them to manipulate. The access for each part of the class
design has been carefully chosen:
public The public part of the class is designed for use by the code that tests how expensive the
sorting algorithm is. An example of testing code is in TestSort.main. This code provides the data
to be sorted and gets the results of the test. For the test code, the metrics are read-only. The public
sort method we provide for the test code ensures that the metrics are initialized before they are
used.Making the actual doSort method protected forces the test code to invoke it indirectly by the
public sort method; thus, we guarantee that the metrics are always initialized and so avoid another
possible error.To the test code, the only available functionality of the class is to drive a test of a particular sorting
algorithm and provide the results. We used methods and access protection to hide the rest of the class,
which should not be exposed to the testing code.•
protected The protected part of the class is designed for use by the sorting code to produce a
properly metered sort. The protected contract lets the sorting algorithm examine and modify the
data to produce a sorted list by whatever means the sort desires. It also gives the sorting algorithm a
context in which it will be properly driven so that it can be measured. This context is the doSort
method.The extended class is not considered trustworthy, and that is why it can access the data only
indirectly, through methods that have access to the data. For example, to hide a comparison by
avoiding compare, the sort would have to use probe to find out what is in the array. Because calls
to probe are also metered, this would, in the end, hide nothing.In addition, getMetrics returns a clone of the actual metrics, so a sorting implementation cannot
modify the values.•
private The class keeps private to itself data that should be hidden from the outsidenamely, the data
being sorted and the metrics. Outside code cannot access these fields, directly or indirectly.•
Recall that to prevent intentional cheating and accidental misuse, SortDouble is designed not to trust its
extended classes. For example, if SortDouble.values (the array being sorted) were protected instead
of private, we could eliminate the probe method because sort algorithms normally count only
comparisons and swaps. But if we eliminated it, the programmer writing an extended class could avoid using
swap to swap data. The results would be invalid in ways that might be hard to notice. Counting probes and
declaring the array private preclude some bugs as well as intentionally devious programming.
If a class is not designed to be extended, it often will be misused by subclasses. If your class will have
subclasses, you should design its protected parts carefully. The end result may be to have no protected
members if extended classes need no special access. If you do not design the protected part of your class,
the class should have no protected members, making subclasses rely on its public contract.
Exercise 3.11: Find at least one security hole in SortDouble that would let a sorting algorithm cheat on its
metrics without getting caught. Fix the security hole. Assume that the sorting algorithm author doesn't get to
write main.
Exercise 3.12: Write a general-purpose SortHarness class that can sort any object type. How would you
provide a way to represent ordering for the objects in a general way, given that you cannot use < to compare