java--Tracing Modeling & __java

Public   abstract   class  Animal {
     public   abstract   void  speak ();
     Public   void  eat () {
         //eat ... 
    }
}

Public   interface  Doorgod {
     void  Guard ();
}

Public   class  Cat  extends  Animal {

    @Override
     public   void  eat () {
         try  {
            thread.sleep (1000);
        }  Catch  (Interruptedexception e) {
            e.printstacktrace ();
        }
         Super. Eat ();
    }

    @Override
     public   void  speak () {
        System.out.println ("Meow");
    }

Public   class  Dog  extends  Animal  implements  doorgod{

    @Override
     public   Void  speak () {
        System.out.println ("barking");
    }

     Public   void  Guard () {while
         (true) {
            System.out.println ("barking");
        }
    
}}

The animal is the base class, the speak and eat methods are defined, and the Eat method gives the null realization; Doorgod is the gate-door interface, the Guard method is defined to guard the house; Cat is a subclass of inherited animal, where it is assumed that the cat has a habit of eating picky, and that it takes some time Dog is also a subclass of inherited animal, and it implements the Doorgod interface to guard the house.

First of all, the trace-back modelling (upcasting). This term is derived from the traditional representation of inheritance graphs: to the top of the base class, and to the downward development of the derivation class. According to the above sample, I give one of the following small applications:

public class Main {public

    static void Upcasting (Animal Animal) {
        animal.speak ();
        Animal.eat ();
    }
    public static void Main (string[] args) {
        Animal dog1 = new Dog ();
        Upcasting (DOG1);
        
        Dog dog2 = new Dog ();
        Upcasting (DOG2);
    }

Because the parameters of the upcasting (Animal Animal) method are Animal types, if the incoming argument is a subclass of Animal, the incoming arguments are converted to the parent class Animal type. So the dog object you create can use only the signature method in animal, that is, in the process of tracing, the dog interface Narrows, and some of its own methods (for example, the Guard method that implements Doorgod) are not visible. If you want to use a method that does not exist in dog and animal (such as the Guard method), it cannot be passed at compile time. This shows that tracing modelling is a safe type of conversion. On the other hand, although the parameters of the upcasting (Animal Animal) method are Animal types, the incoming arguments can be Animal derived classes (this is also the usual programming method in OO programming), where there is an object type identification problem, which is run-time type recognition ( Run-time type identification, abbreviated as RTTI), this can also write a separate article, "Thinking in Java," the 10th chapter elaborated in detail Rtti.

Relative to the type of conversion safety of the back of the modelling, the next shape is not necessarily safe. We often do some forced type conversions, and sometimes we inadvertently encounter classcastexception conversion exceptions (from which we should use generics to avoid unsafe type conversions). For example:

public static void Downcasting (Animal Animal) {
        //doorgod Doorgod = (doorgod) Animal;
        if (animal instanceof doorgod) {
            Doorgod Doorgod = (doorgod) animal;
            Doorgod.guard ();
        }
        if (animal instanceof cat) {
            cat cat = (cat) animal;
            Cat.speak ();
        }

If no measures are taken (the measures used above are instanceofTo determine the type of object, a downward cast is not secure. This conversion error can not be detected at compile time, only at runtime will throw ClassCastException exception, for testing, such errors are difficult to detect.

Source: http://www.blogjava.net/kafka0102/archive/2007/05/21/118998.html