Java language interface and the nature of inheritance

Computer College Grind two brothers and I discuss Java, a meeting, a few questions are all about the interface, what is the use of the interface? Why should I use an interface? When should I use an interface? I'm glad they're not asking me how Java connects to SQL Server, or how to develop EE applications, and this kind of problem is lethal, To avoid it is auspicious. This year, the University of Computer science has a graduation project is to do J2ME, selected this topic students in the end of May are still face study java.util.* This bag, this ... Alas.

Most people think that the meaning of interfaces is to replace multiple inheritance. It is well known that Java does not have multiple inheritance mechanisms like C + +, but it can implement multiple interfaces. In fact, this is very far-fetched, interface and inheritance is a completely different thing, the interface does not have the ability to replace multiple inheritance, there is no obligation. The function of the interface, Word, is the category of the Flag class (Type of Class). By attributing different types of classes to different interfaces, you can better manage them. The essence of Oo, I think, is the object of abstraction, the most embodiment of this is the interface. Why we discuss the design patterns are only for the language with the abstract ability (such as C + +, Java, C #, etc.), because the design pattern is studied, in fact, is how to the rational abstraction. (Cowboy's famous saying is "Abstract is the part that pulls out the image", seemingly ridicule, actually is the rationale).

The most basic design pattern is the Factory mode (Factory), in my recent simple application, I want to try my best to allow my program to migrate across multiple databases, of course, this involves a lot of problems, and how to be compatible with the different DBMS SQL makes a person headache. We might as well simplify the issue and consider only how to connect to different databases.

Suppose I have many classes, namely Mysql.java, Sqlserver.java, Oracle.java, Db2.java, they connect to separate databases, return a Connection object uniformly, and have a close method for closing the connection. You just need to select a different class for your DBMS, but what database does my user use? I don't know, I want to change the code as little as possible to meet his needs. I can abstract the following interface:

Package org.bromon.test;

public interface DB

{

Java.sql.Connection opendb (String url,string user,string password);

void Close ();

}

This interface defines only two methods, without any meaningful code, and the specific code is given by the class that implemented the interface, such as Mysql.java:

Package org.bromon.test;

Import java.sql.*;

public class Mysql implements DB

{

Private String url= "Jdbc:mysql:localhost:3306/test";

Private String user= "root";

Private String password= "";

Private Connection Conn;

Public Connection opendb (Url,user,password)

{

Code to connect to a database

}

public void Close ()

{

Close Database

}

}

Like, of course, Oracle.java and so on, interface db gives these classes a class that we define in the application:

Org.bromon.test.DB MyDB;

Using MyDB to manipulate the database, you can do without having to control which class I actually use, which is called the "open-closed" principle. But the problem is that the interface is not instantiated, Mydb=new DB (), such code is absolutely wrong, we can only mydb=new Mysql () or Mydb=new Oracle (). Trouble, I still need to specify the specific instantiation of which class, with the interface and useless. So we need a factory:

Package org.bromon.test;

public class Dbfactory

{

public static DB Connection Getconn ()

{

Return (new Mysql ());

}

}

So the instantiated code becomes: Mydb=dbfactory.getconn ();

This is the most basic common factory in 23 models (Factory), where the factory class is responsible for instantiating which class, while the other program logic operates on the DB interface, which is "programming for interfaces." Responsibility is passed on to the factory, of course, you can continue to define the factory interface, continue to throw responsibility, which evolved into an abstract factory (abstraction Factory).

The interface is not responsible for any specific operations throughout the process, other programs to connect to the database, only need to construct a DB object OK, regardless of how the factory class changes. This is the meaning----abstraction of the interface.

The concept of inheritance is not to be said, it is well understood. Why inherit it? Because you want to reuse code? This is absolutely not a reason, and the meaning of inheritance is abstraction, not code reuse. If object A has a run () method, object B would also like to have this method, so someone extends a on class B. This is done without the brain. If you instantiate a A in B and call the Run () method of a, do you achieve the same purpose?

Class B

{

A a=new a ();

A.run ();

}

This is the use of class aggregation to reuse code, is the prototype of the delegation model, is GOF always advocated practice.

So what is the meaning of inheritance? In fact, this is caused by historical reasons, the beginning of oo language only inheritance, there is no interface, so you can only use inheritance to implement abstractions, please be aware that inheritance is meant to be abstract rather than code reuse (although inheritance has this effect), which is one of the most serious errors in Java bad books, They caused the shadow, I have not yet completely rid of, bad books harm Ah, especially in the category, Poison too big. When should you use inheritance? Only used in abstract classes, in other cases try not to use. An abstract class is also not instantiated, it simply provides a template, which is a good illustration of the problem.

Software development is the root of all evils, one is to repeat the code instead of reusing code, the second is rotten with inheritance, especially in C + + programmers. In Java, banning multiple inheritance is a very sensible way to stop rotten inheritance, but many people don't understand it. Java is a better embodiment of design, which is one of the reasons that fascinated me.