is Rtti harmful?

The various designs in this chapter are trying to avoid the use of rtti, which may leave you with a "rtti" impression (remember poor Goto, which was never put into Java because of the poor impression). But the reality is not absolutely so. Correctly speaking, it should be rtti improper use is "harmful". The reason why we want to avoid the use of rtti is that it can cause the extensibility to be compromised by its erroneous application. Our goal in advance is to be able to add new types to the system, while ensuring the smallest possible impact on the surrounding code. Because Rtti is often abused (let it look for each type in the system), it can greatly compromise the scalability of the code-when adding a new type, you must find all the code that uses Rtti. Even if you omit only one of them, you cannot get any help from the compiler.
However, Rtti itself does not automatically generate non extensibility code. Let's take a look at the example of garbage collection mentioned earlier. This time I'm going to introduce a new tool, I call it typemap. It contains a Hashtable (hash table) with multiple vectors, but the interface is simple: You can add (add ()) A new object, and you can get a vector that contains all the objects that belong to a particular type. The key to this included hash table is the type in the corresponding vector. The advantages of this design (according to Larry O ' Brien) are that when a new type is encountered, Typemap dynamically adds a new type. So whenever a new type is added to the system, even when it is run, it is correctly accepted.
Our example is also based on C16. Trash the Trash type structure within this "package" (Package) (and the Trash.dat files used there can be copied here).

 

: Dynatrash.java//Using a Hashtable of Vectors and RTTI//to automatically sort trash into//Vectors.
This solution, despite the "/" RTTI, is extensible.
Package C16.dynatrash;
Import c16.trash.*;

Import java.util.*;
  Generic Typemap works with any situation:class typemap {private Hashtable t = new Hashtable ();
    public void Add (Object o) {Class type = O.getclass ();
    if (T.containskey (type)) (Vector) T.get (type). addelement (o);
      else {vector v = new vector ();
      V.addelement (o);
    T.put (TYPE,V);
  The public Vector get (Class type) {return (Vector) t.get (type);
  Public enumeration keys () {return T.keys ();}  Returns handle to adapter class to allow/callbacks from Parsetrash.fillbin (): Public fillable filler () {//
    Anonymous Inner Class:return New fillable () {public void Addtrash (Trash t) {Add (t);}
  }; } public class Dynatrash {public static void main (string[] args) {Typemap bin = new Typemap ();
    Parsetrash.fillbin ("Trash.dat", Bin.filler ());
    Enumeration keys = Bin.keys ();
  while (Keys.hasmoreelements ()) Trash.sumvalue (Bin.get (Class) keys.nextelement ()); }
} ///:~

The

is very simple to define TYPEMAP, despite its strong functionality. It only contains a hash table, while add () is responsible for most of the work. When a new type is added, the handle of that type of class object is extracted. The handle is then used to determine whether a vector containing the object already exists in the hash table. If the answer is yes, the vector is extracted and the object is added to it, and conversely, the class object and the new vector are added as a "key-value" pair. The
Use the keys () to get an "enumeration" of all class objects (enumeration), and get (), which can be used to obtain the corresponding vector from the class object. The
Filler () method is interesting because it takes advantage of the design of Parsetrash.fillbin ()-not only to try to populate a vector, but also to use its Addtrash () method to try to populate anything that implements a fillable (populated) interface. All you need to do is return a handle to an interface that implements the Fillable, and then pass the handle as a parameter to Fillbin (), as follows:
Parsetrash.fillbin ("Trash.dat", Bin.filler ());
to produce this handle, we used an "Anonymous inner class" (described in chapter 7th). Since it is not necessary to implement fillable with a named class, only the handle of an object belonging to that class is required, so it is appropriate to use the anonymous inner class here.
One place to note for this design is that, although not designed to control the collation, a trash object is inserted into the bin each time the Fillbin () is categorized.
by learning from those previous examples, most parts of the Dynatrash class should be very familiar. This time, we no longer place the new trash object in a bin of type vector. As the bin type is Typemap, the TYPEMAP internal collation mechanism is immediately properly categorized when the garbage (Trash) is thrown into the garbage bin. Traversing and manipulating each vector in Typemap is a fairly simple thing to do:

 

    Enumeration keys = Bin.keys ();
    while (Keys.hasmoreelements ())
      Trash.sumvalue (
        bin.get (Class) keys.nextelement ());

As you can see, the addition of the new type to the system does not affect the code at all, nor does it affect the code in the Typemap. This is clearly the most successful solution to the problem. Although it does rely heavily on RTTI, note that each key-value pair in the hash table finds only one type. In addition, when we add a new type, we don't get bogged down in the embarrassment of "forgetting" adding the correct code to the system, because there is no code to add.