澄清Java語言介面與繼承的本質(轉)
澄清Java語言介面與繼承的本質(轉)[@more@] 大多數人認為,介面的意義在於頂替多重繼承。眾所周知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能夠更好的體現設計,這是讓我入迷的原因之一。
設計模式中最基礎的是工廠模式(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能夠更好的體現設計,這是讓我入迷的原因之一。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10617542/viewspace-960214/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 繼承與介面 (轉)繼承
- Java 自學 - 介面與繼承 介面Java繼承
- Java中介面與繼承的區別Java繼承
- C++批判系列5--繼承的本質 (轉)C++繼承
- 從本質認識JavaScript的原型繼承和類繼承JavaScript原型繼承
- Java繼承和介面Java繼承
- Go語言封裝、繼承、介面、多型和斷言的案例Go封裝繼承多型
- Java介面之間的繼承Java繼承
- C++程式設計批評系列 繼承的本質(轉)C++程式設計繼承
- C++高階教程之繼承得本質:單繼承(一)C++繼承
- 繼承(extends)與介面( implements)繼承
- Java的類與繼承Java繼承
- 解析Java語言的介面與型別安全(轉)Java型別
- JAVA介面繼承、抽象類等Java繼承抽象
- Java基礎10 介面的繼承與抽象類Java繼承抽象
- Java:類與繼承Java繼承
- java 繼承的基礎(轉)Java繼承
- class語法與繼承繼承
- java繼承與多型Java繼承多型
- TypeScript 介面繼承TypeScript繼承
- Java中的繼承與組合Java繼承
- C語言實現繼承多型C語言繼承多型
- Java的繼承Java繼承
- Java程式碼塊與Java繼承Java繼承
- C語言的本質(32)——C語言與彙編之C語言內聯彙編C語言
- 多繼承 與 多重繼承繼承
- Go語言slice的本質-SliceHeaderGoHeader
- C語言的本質(35)——共享庫C語言
- C語言如何實現繼承及容器C語言繼承
- Java中的類繼承與多型Java繼承多型
- Java繼承Java繼承
- TypeScript 介面繼承類TypeScript繼承
- Java繼承的使用Java繼承
- java中的繼承Java繼承
- 類的繼承,介面的使用繼承
- 重繼承、介面和異常處理 (轉)繼承
- Java 繼承與多型實驗Java繼承多型
- 程式語言:型別系統的本質型別