在最近學習PHP5介面的過程中遇到了困難，書中說是實現多重繼承的一種方式，但我仍然不知道具體該如何實現。在網路上查PHP介面的資料很少，就查了java的，其實基本上都差不多。看完《澄清Java（介面與繼承）》這篇文章才恍然大悟，原來我一開始理解就有誤，所謂的多重繼承是指介面繼承類，而不是類繼承介面。
文章中提到了OO的抽象，正如文章中的那句話－－"抽象就是抽去像的部分"，很形象，以前想到抽象總是認為很難理解，抽象嘛，哈哈，現在就很容易理解了，這也正是介面和抽象類別要做的事情。
文章中還有很多觀點也讓我受益匪淺，羅列如下：
OO的精髓，我以為，是對對象的抽象。
介面的作用，一言以蔽之，就是標誌類別的類別（type of class）。把不同類型的類別歸於不同的接口，可以更好的管理他們。
繼承的意義也在於抽象，而不是程式碼重用。
看完這篇文章，現在基本上理解介面、抽象類別、繼承該如何應用了。
原文如下：
澄清Java（介面與繼承） 電腦學院研二的兄弟與我討論Java，一見面，幾個問題全是關於接口，接口有什麼用？為什麼要用介面？什麼時候該使用介面？很慶幸他們不是問我Java如何連接SQL Server，或是如何開發J2EE應用，這類問題有殺傷力，避之則吉。今年電腦學院本科有個畢業設計課題是做J2ME，選這個題目的學生在5月末都還在苦著臉研究java.util.*這個包，這個這個……唉。
大多數人認為，介面的意義在於頂替多重繼承。眾所周知Java沒有c++那樣多重繼承的機制，但是卻能夠實現多個介面。其實這樣做是很牽強的，介面和繼承是完全不同的東西，介面沒有能力取代多重繼承，也沒有這個義務。介面的作用，一言以蔽之，就是標誌類別的類別（type of class）。把不同類型的類別歸於不同的接口，可以更好的管理他們。 OO的精髓，我以為，是對物件的抽象，最能體現這一點的就是介面。為什麼我們討論設計模式都只針對具備了抽象能力的語言（例如c++、java、c#等），就是因為設計模式所研究的，實際上就是如何合理的去抽象。 （cowboy的名言是“抽象就是抽去像的部分”，看似調侃，實乃至理）。
設計模式中最基礎的是工廠模式（Factory），在我最近的一個很簡單的應用中，我想盡量的讓我的程式能夠在多個資料庫間移植，當然，這涉及很多問題，單是如何相容於不同DBMS的SQL會讓人頭痛。我們不妨先把問題簡化，只考慮如何連接不同的資料庫。
假設我有很多個類，分別是Mysql.java、SQLServer.java、Oracle.java、DB2.java，他們分別連接不同的資料庫，統一傳回一個Connection對象，而且都有一個close方法，用來關閉連線。只需要針對你的DBMS，選擇不同的類，就可以用了，但是我的用戶他會使用什麼資料庫？我不知道，我希望的是盡量少的修改程式碼，就能滿足他的需要。我可以抽像如下介面：
package org.bromon.test;
public interface DB
{
java.sql.Connection openDB(String url,String user,String password);
void close();
}
這個介面只定義兩個方法，沒有任何有實際意義的程式碼，具體的程式碼由實作這個介面的類別來給出，例如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)
{
//連接資料庫的程式碼}
public void close()
{
//關閉資料庫}
}
類似的當然還有Oracle.java等等，介面DB給這些類別歸了個類，在應用程式中我們這樣定義物件：
org.bromon.test.DB myDB;
使用myDB來操作資料庫，就可以不用管實際上我所使用的是哪個類，這就是所謂的「開-閉」原則。但問題在於介面是不能實例化的，myDB=new DB()，這樣的程式碼是絕對錯誤的，我們只能myDB=new Mysql()或myDB=new Oracle()。麻煩了，我還是需要指定具體實例化的是哪個類，用了介面跟沒用一樣。所以我們需要一個工廠：
package org.bromon.test;
public class DBFactory
{
public static DB Connection getConn()
{
Return(new Mysql());
}
}
所以實例化的程式碼變成：myDB=DBFactory.getConn()；
這就是23種模式中最基礎的普通工廠(Factory)，工廠類別負責具體實例化哪個類，而其他的程式邏輯都是針對DB這個介面進行操作，這就是「針對介面程式設計」。責任都被推卸給工廠類了，當然你也可以繼續定義工廠接口，繼續把責任上拋，這就演變成抽象工廠(Abstract Factory)。
整個過程中介面不負責任何特定操作，其他的程式要連接資料庫的話，只需要建構一個DB物件就OK，而不管工廠類別如何變化。這就是介面的意義----抽象。
繼承的概念不用多說，很好理解。為什麼要繼承呢？因為你想重複使用程式碼？這絕對不是理由，繼承的意義也在於抽象，而不是程式碼重用。如果物件A有一個run()方法，物件B也想有這個方法，所以有人就Class B extends A。這是不經大腦的做法。如果在B中實例化一個A，呼叫A的Run()方法，是不是可以達到同樣的目的？如下：
Class B
{
A a=new A();
a.run();
}
這就是利用類別的聚合來重複使用程式碼，是委派模式的雛形，是GoF一貫倡導的做法。
那麼繼承的意義何在？其實這是歷史原因造成的，最開始的OO語言只有繼承，沒有接口，所以只能以繼承來實現抽象，請一定注意，繼承的本意在於抽象，而非代碼重用（雖然繼承也有這個作用），這是許多Java爛書最嚴重的錯誤之一，它們所造成的陰影，我至今還沒有完全擺脫，壞書害人啊，尤其是入門類的，流毒太大。什麼時候該使用繼承？只在抽象類別中使用，其他情況下盡量不使用。抽象類別也是不能實例化的，它只提供一個模版而已，這就很能說明問題。
軟體開發的萬惡之源，一是重複程式碼而不是重用程式碼，二是爛用繼承，尤以c++程式設計師為甚。 Java中取締多重繼承，目的就是製止爛用繼承，實是非常明智的做法，不過很多人都不理解。 Java能夠更好的體現設計，這也是讓我入迷的原因之一。