Analog garbage Collection Station

The essence of the problem is that if you throw rubbish into a single trash bin, it is actually unclassified. But in the future, some special information must be restored so that the rubbish is properly categorized. In the first solution, Rtti played a key role (see chap. 11th).
This is not a common design because it adds a new limit. It is this restriction that makes the problem very interesting-it is more like the very troublesome problems we encounter at work. The extra restriction is that when the rubbish arrives at the garbage collection station, it is all mixed together. The program must set a model for the classification of those rubbish. This is where Rtti works: We have a lot of unknown rubbish, and the program will correctly determine which type they belong to.

 

: 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.nexte
      Lement ();
      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 < 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); }
} ///:~

The first place to note is the package statement:
Package C16.recyclea;
This means that in the source directory used in this book, the file will be placed in the Recyclea subdirectory that is branched from the C16 (the program representing the 16th chapter). The 17th chapter of the Unpack tool is responsible for placing it in the correct subdirectory. The reason for this is that this chapter will rewrite this particular example several times, and each version of it will be placed in its own "package" (package) to avoid conflict of class names.
Several vector objects are created to hold the trash handle. Of course, vectors actually hold objects, so they can eventually hold anything. The only reason for them to accommodate trash (or something else derived from trash) is that we need to be careful not to put anything other than trash. If you really put something "wrong" into the vector, you won't get an error or warning at compile time--only one violation of the runtime knows that you've made a mistake.
After the trash handle is added, they will lose their specific identity information and will only be a simple object handle (traced). However, because of the polymorphism factor, the correct behavior will occur once the result object has been styled back to trash when we invoke the dynamic binding method via enumeration sorter. Sumvalue () also operates on each object in the vector with a enumeration.
On the surface, it seems a very foolish way to trash the type of the form into a set containing the underlying type of handle, and then back to the shape again. Why not just start by putting the rubbish into the proper container? (This is, in fact, the key to a "recycling" cloud.) In this program, we can easily switch to this approach, but in some cases, the structure and flexibility of the system can be greatly benefited from the traceability.
The program has satisfied the original design: it can work properly! As long as it is a one-off plan, it will look very good. However, a truly useful program should be able to solve problems at any time. So you have to ask yourself this question: "Can it work if things change?" "For example, thick cardboard is now a valuable recyclable item, so how do you integrate it into the system (especially when the program is very complex)?" Because the type-checking encoding in the previous switch statement might be scattered throughout the program, all of those encodings must be found each time a new type is added. If you omit one, the compiler cannot provide any valuable help in addition to pointing out that there is an error.
The key to Rtti's improper use here is "test every type." If a subset of the types requires special treatment, the only way to find that subset is to get better. But if you look up each type in a switch statement, you're likely to miss a focus, making the final code difficult to maintain. In the next section, you'll learn how to evolve this program to make it more flexible. This is a very meaningful example in programming.