Bruce Eckel’s Thinking in Java | Contents | Prev | Next |
nature of this problem is that the trash is thrown unclassified into a single
bin, so the specific type information is lost. But later, the specific type
information must be recovered to properly sort the trash. In the initial
solution, RTTI (described in Chapter 11) is used.
is not a trivial design because it has an added constraint. That’s what
makes it interesting – it’s more like the messy problems
you’re likely to encounter in your work. The extra constraint is that the
trash arrives at the trash recycling plant all mixed together. The program must
model the sorting of that trash. This is where RTTI comes in: you have a bunch
of anonymous pieces of trash, and the program figures out exactly what type
they are.
//: RecycleA.java // Recycling with RTTI package c16.recyclea; import java.util.*; import java.io.*; abstract class Trash { private double weight; Trash(double wt) { weight = wt; } abstract double value(); double weight() { return weight; } // Sums the value of Trash in a bin: static void sumValue(Vector bin) { Enumeration e = bin.elements(); double val = 0.0f; while(e.hasMoreElements()) { // One kind of RTTI: // A dynamically-checked cast Trash t = (Trash)e.nextElement(); // Polymorphism in action: val += t.weight() * t.value(); System.out.println( "weight of " + // Using RTTI to get type // information about the class: t.getClass().getName() + " = " + t.weight()); } System.out.println("Total value = " + val); } } class Aluminum extends Trash { static double val = 1.67f; Aluminum(double wt) { super(wt); } double value() { return val; } static void value(double newval) { val = newval; } } class Paper extends Trash { static double val = 0.10f; Paper(double wt) { super(wt); } double value() { return val; } static void value(double newval) { val = newval; } } class Glass extends Trash { static double val = 0.23f; Glass(double wt) { super(wt); } double value() { return val; } static void value(double newval) { val = newval; } } public class RecycleA { public static void main(String[] args) { Vector bin = new Vector(); // Fill up the Trash bin: for(int i = 0; i < 30; i++) switch((int)(Math.random() * 3)) { case 0 : bin.addElement(new Aluminum(Math.random() * 100)); break; case 1 : bin.addElement(new Paper(Math.random() * 100)); break; case 2 : bin.addElement(new Glass(Math.random() * 100)); } Vector glassBin = new Vector(), paperBin = new Vector(), alBin = new Vector(); Enumeration sorter = bin.elements(); // Sort the Trash: while(sorter.hasMoreElements()) { Object t = sorter.nextElement(); // RTTI to show class membership: if(t instanceof Aluminum) alBin.addElement(t); if(t instanceof Paper) paperBin.addElement(t); if(t instanceof Glass) glassBin.addElement(t); } Trash.sumValue(alBin); Trash.sumValue(paperBin); Trash.sumValue(glassBin); Trash.sumValue(bin); } } ///:~
c16.recyclea;
means that in the source code listings available for the book, this file will
be placed in the subdirectory
recyclea
that branches off from the subdirectory
c16
(for Chapter 16). The unpacking tool in Chapter 17 takes care of placing it
into the correct subdirectory. The reason for doing this is that this chapter
rewrites this particular example a number of times and by putting each version
in its own
package
the class names will not clash.
Vector
objects are created to hold
Trash
handles. Of course,
Vectors
actually
hold
Objects
so they’ll hold anything at all. The reason they hold
Trash
(or
something derived from
Trash)
is only because you’ve been careful to not put in anything except
Trash.
If you do put something “wrong” into the
Vector,
you won’t get any compile-time warnings or errors – you’ll
find out only via an exception at run-time.
the
Trash
handles are added, they lose their specific identities and become simply
Object
handles (they are upcast).
However, because of polymorphism the
proper behavior still occurs when the dynamically-bound methods
are called through the Enumeration
sorter,
once the resulting Object
has been cast back to
Trash.
sumValue( )
also uses an
Enumeration
to
perform operations on every object in the
Vector.
looks silly to upcast the types of
Trash
into a collection holding base type handles, and then turn around and downcast.
Why not just put the trash into the appropriate receptacle in the first place?
(Indeed, this is the whole enigma of recycling). In this program it would be
easy to repair, but sometimes a system’s structure and flexibility can
benefit greatly from downcasting.
program satisfies the design requirements: it works. This might be fine as long
as it’s a one-shot solution. However, a useful program tends to evolve
over time, so you must ask, “What if the situation changes?” For
example, cardboard is now a valuable recyclable commodity, so how will that be
integrated into the system (especially if the program is large and
complicated). Since the above type-check
coding in the
switch
statement could be scattered throughout the program, you must go find all that
code every time a new type is added, and if you miss one the compiler
won’t give you any help by pointing out an error.
key to the misuse
of RTTI here is that
every
type is tested
.
If you’re looking for only a subset of types because that subset needs
special treatment, that’s probably fine. But if you’re hunting for
every type inside a switch statement, then you’re probably missing an
important point, and definitely making your code less maintainable. In the next
section we’ll look at how this program evolved over several stages to
become much more flexible. This should prove a valuable example in program
design.