Java：如何通过调用父类的子类获取对象

Question

import java.util.*;
import java.lang.*;
import java.io.*;

class mainA {
   private mainA obj;

public mainA(int type) {
  System.out.println("accessing mainA");
  switch(type) {
     case 1:
        obj = new mysql();
        break;

     case 2:
        obj = new mssql();
        break;

     default:
        break;
   }
  }
}

class mysql extends mainA {
  public void printme() {
    System.out.println("accessing mysql");
  } 
}

class mssql extends mainA {
  public void printme() {
    System.out.println("accessing mssql");
  }
}

class C2 extends mainA {

   public C2() {
      super();
   }
   public static void main(String args[]){
      Object b = new C2();
      b.printme();
   }
 }

I need to achieve the following scenario. It would be great if someone can help me out. I'm trying to create a common API library set which can be scaled to as many backend databases as possible.

The idea is to create an object of C2, which in turn would return the value of either mysql/mssql based on the dbtype. The type parameter can be obtained from any where in the code. mainA is the super class which consists of config params. Type can be obtained here as well. The problem here is that I'm stuck with not being able to get the object of mysql/mssql from C2. The ideal situation would be to create an object of C2 which refers to mainA that gets the type and inits either mssql/mysql. C2.printme must call the db class which was specified in the type.

Would generic classes be of any help here?

Answer 1

you can have an instanceof test to cast the object but it is lame as you would have to change your code if you are adding a new type of DB object.

You can have a good interface and make the subclasses implement it so that you can call through your interface without caring about the actual implementation object.

Coding to Interface is what you should be doing.

Answer 2

You've got some work ahead of you. You'll want to read up on interfaces. In your example, you can do something like the following (it's a bit silly in the real world).

Let's call our interface Printable.java (by convention, starts with either the capital letter "I" or ends in "-ible", "able," etc). I wouldn't really call it Printable, but for the purpose of this example:

public interface Printable {
   public void logDatabaseType();
}

Your parent class (we can make it abstract so that it cannot be created directly without an underlying implementation):

public abstract class Database implements Printable {
    @Override
    public void logDatabaseType() {
        System.out.println("logDatabaseType()");
    }
}    

Your subclasses:

public class MySQL extends Database implements Printable {
    @Override
    public void logDatabaseType() {
       System.out.println("Accessing MySQL");
    }
}

public class MicrosoftSQL extends Database implements Printable {
    @Override
    public void logDatabaseType() {
       System.out.println("Accessing MSSQL");
    }
}

In your test class (you should try to get your feet wet with JUnit as early as possible):

 public class DatabaseLogTest {

   @Test
   public void printDatabaseType() {
       //programming by interface
       Printable printable = new MySql();         
       printable.logDatabaseType();

       printable = new MicrosoftSQL();
       printable.logDatabaseType();

       //then later you can do 
       //someMethod(printable);
       //and the printable object will retain whatever was instantiated
       //and someMethod will be blissfully ignorant of the actual implementation
    } 

}

@Override is important because it tells your IDE and the developer that you're overriding an implementation and the IDE will spit out errors if the implied contract is not met. You should have this whenever you're overriding.

You'd also want to use a logger (eg, SLF4j over Log4J or logback) rather than System.out.println() method calls.