The application of abstraction

To get to this point, it's time to think about the rest of the design-where do you use classes? Since the method of classifying to the dustbin is very indecent and too revealing, why not isolate the process and hide it in a class? This is the famous "If you have to do something indecent, you should at least localize it into a class" rule. It looks just like the following:

Now, as long as a new type of trash is added, the initialization of the Trashsorter object must change. As you can imagine, the Trashsorter class should look something like the following:
Class Trashsorter extends Vector {
void sort (Trash t) {/* ... */}
}
That is, the trashsorter is a vector (series) of a series of handles, and those handles point to a vector made up of trash handles; with AddElement (), you can install a new trashsorter as follows:
Trashsorter ts = new Trashsorter ();
Ts.addelement (New Vector ());
But now, sort () has become a problem. How does a static coding method deal with the fact that a new type joins? To solve this problem, you must remove the type information from the sort () so that all it needs to do is invoke a generic method that takes care of all the details involved in the type processing. This is, of course, another way of describing a dynamic binding method. So sort () simply iterates through the sequence and invokes a dynamic binding method for each vector. Because the task of this method is to collect the rubbish that it is interested in, it is called grab (Trash). The structure now becomes the following:

Where Trashsorter needs to invoke each grab () method, and then, depending on what type the current vector holds, a different result is obtained. In other words, vectors must be mindful of the type they hold. The traditional way to solve this problem is to create a basic "Trash bin" class and inherit a new derived class for each of the different types you want to accommodate. If Java has a parameterized type mechanism, it may be the most straightforward approach. But for the various classes that this mechanism should build for us, we should not be able to do troublesome manual coding, and later "observation" mode provides a better way to encode.
OOP design a basic guideline is "Use data members for changes in state, use polymorphism for behavioral changes". For the vector that holds the paper (paper) and the vector that holds the glass (glass), you may start to think that the grab () method used separately for them will certainly produce different behaviors. But what exactly depends on the type, not something else. It can be interpreted as a different state, and because Java has a class that can represent a type (class), it is used to determine what type of trash a particular tbin is to hold. The
Builder for Tbin requires that we pass a class of our choice to it. Doing so tells the vector what type it wants to hold. The grab () method then uses class Bintype and rtti to check whether the Trash object we pass to it matches the type it wants to collect.
The complete solution is listed below. The number set to the annotation (such as *1*) is easy to compare with the instructions listed later in the program.

 

: Recycleb.java//Adding more objects to the recycling problem package;
Import c16.trash.*;

Import java.util.*;
  A vector that admits to the right Type:class Tbin extends vector {class bintype; 
  Tbin (Class bintype) {this.bintype = Bintype;
      Boolean grab (Trash t) {//Comparing class Types:if (T.getclass (). Equals (Bintype)) {addelement (t); return true; Object grabbed} return false; Object not grabbed}} class Tbinlist extends Vector {//(*1*) Boolean sort (Trash t) {enumeration E = element
    S ();
      while (E.hasmoreelements ()) {Tbin bin = (tbin) e.nextelement ();
    if (Bin.grab (t)) return true; return false;
    Bin not found for t} void Sortbin (Tbin bin) {//(*2*) Enumeration e = Bin.elements ();
  while (E.hasmoreelements ()) if (!sort (Trash) e.nextelement ()) System.out.println ("Bin not Found"); } public class Recycleb {static Tbin bin = new Tbin (trash.class);

    public static void Main (string[] args) {//Fill up the Trash bin:ParseTrash.fillBin ("Trash.dat", bin);
    Tbinlist trashbins = new Tbinlist ();
    Trashbins.addelement (New Tbin (Aluminum.class));
    Trashbins.addelement (New Tbin (Paper.class));
    Trashbins.addelement (New Tbin (Glass.class));

    Add one line here: (*3*) trashbins.addelement (new Tbin (Cardboard.class)); Trashbins.sortbin (BIN);
    (*4*) Enumeration e = Trashbins.elements ();
      while (E.hasmoreelements ()) {Tbin b = (tbin) e.nextelement ();
    Trash.sumvalue (b);
  } trash.sumvalue (BIN); }
} ///:~

(1) The Tbinlist accommodates a series of tbin handles, so the sort () can inherit through Tbin when looking for a situation that matches the Trash object that we pass to it.
(2) Sortbin () allows us to pass a complete tbin, and it traverses the Tbin, picks out each trash, and classifies it into a specific tbin. Note the versatility of this code: When a new type joins, it does not need any changes. As long as the new type joins (or other events), a lot of code doesn't need to change, which means we're designing an easily scalable system.
(3) It is now possible to realize how easy it is to add new types. To support adding, you just need to change a few lines of code. If necessary, you can even further refine your design so that more code remains "fixed."
(4) A method call causes the contents of the bin to be categorized into the corresponding, specific type of garbage cans.