澄清Java语言接口与继承的本质

大多数人认为接口的意义是取代多重继承。众所周知，Java没有c++那样的多重继承的机制，但是可以实现多个接口。其实这很牵强。接口和继承完全是两码事，接口没有能力代替多重继承，也没有这个义务。接口的作用，一句话，就是标记类的类型。将不同类型的类划分到不同的接口中可以更好地管理它们。OO的本质，我认为是对象的抽象，接口最能体现这一点。为什么我们只讨论具有抽象能力的语言(如c++、java、c#等)的设计模式。)?是因为设计模式研究的其实就是如何合理抽象。(牛仔的名言是“抽象是拿走形象的部分”，看似可笑，实际甚至合理)。
最基本的设计模式是工厂模式。在我最近的一个简单的应用程序中，我想尽力使我的程序在多个数据库之间可移植。当然这涉及到很多问题，只是如何兼容不同DBMS的SQL就很头疼了。我们把问题简化一下，只考虑如何连接不同的数据库。

假设我有许多班级，即Mysql.java、SQLServer.java、Oracle.java和DB2.java。它们连接不同的数据库，返回一个连接对象，并且都有一个关闭连接的close方法。只需为您的DBMS选择一个不同的类，就可以使用它了。但是我的用户将使用什么数据库呢？我不知道，我希望的是尽量少修改代码，满足他的需求。我可以抽象出以下接口:

包org . bromon . test；
公共接口DB
{
Java . SQL . connection openDB(字符串url，字符串用户，字符串密码)；
void close()；
}
这个接口只定义了两个方法，没有任何有意义的代码。具体代码由实现这个接口的类给出，比如Mysql.java:

包org . bromon . test；
导入Java . SQL . *；
公共类Mysql实现DB
{
私有字符串URL = " JDBC:Mysql:localhost:3306/test "；
私有字符串user = " root
私有字符串password =
专用连接连接器；
公共连接openDB(url，用户，密码)

{
//连接数据库的代码
}
public void close()

{
//关闭数据库
}
当然还有Oracle.java等等。接口DB将这些类分类成一个类。在应用程序中，我们这样定义对象:

org . bromon . test . db myDB；
通过使用myDB操作数据库，可以忽略我实际使用的是哪个类。这就是所谓的“开闭”原理。但问题是接口不能实例化，myDB=new DB()。这样的代码是绝对错误的。我们只能用myDB=new Mysql()或者myDB=new Oracle()。抱歉，我仍然需要指定实例化哪个类。用界面一样没用。所以我们需要一个工厂:

包org . bromon . test；
公共类DBFactory
{
公共静态数据库连接getConn()

{
Return(new Mysql())；
}
}

于是实例化的代码就变成了:mydb = db factory . get conn()；

这是23种模式中最基本的常见工厂。工厂类负责实例化哪个类，其他程序逻辑在接口DB上操作，这就是“为接口编程”。责任都推卸到工厂阶级身上了。当然，你可以继续定义工厂接口，把责任丢掉，这样就会演变成一个抽象的工厂。

在整个过程中，接口不负责任何具体操作。如果其他程序想要连接数据库，那么无论工厂类如何变化，只需要构造一个DB对象即可。这就是接口抽象的意义。

不用说，继承的概念很容易理解。为什么要继承？因为你想重用代码？肯定不是这个原因。继承的意义在于抽象，而不在于代码重用。如果对象A有run()方法，那么对象B也想有这个方法，于是有人就classb扩展了A，这是一种无脑的做法。如果在B中实例化一个A，调用A的Run()方法，能否达到同样的目的？如下所示:

class B
{
A A = new A()；
a . run()；
}
这是利用类聚合来复用代码，是委托模式的雏形，也是GoF一贯倡导的做法。

那么传承的意义是什么？其实这是历史原因造成的。原来的OO语言只有继承，没有接口，只能通过继承来抽象。请注意，继承的初衷是抽象，不是代码重用(虽然继承也有这个功能)。这是很多Java坏书最严重的错误之一，我还没有完全摆脱它们造成的阴影。坏书害人，尤其是初学者，其毒害太大。什么时候应该使用继承？只在抽象类中使用，其他情况尽量不要使用。抽象类也不能实例化，只提供一个模板，这就很能说明问题了。

软件开发万恶之源，一是重复代码而不是重用代码，二是不好好利用继承，对于c++程序员来说尤其如此。Java禁止多重继承，目的是阻止不良继承，这是非常明智的做法，但是很多人不理解。Java更能体现设计，这也是我着迷的原因之一。