經典解釋是:使用了對象就叫基于對象,基于對象的基礎上增加了繼承從而變成了面向對象。 基于對象的最大特點就是封裝,至于private,protected,public,并不是基于對象語言的必須要求。同時應該注意到的是,封裝對于應用本身并沒有提供太大的幫助;換句話說封裝僅僅改變了方法的表達形式,除了析構函數能夠提供一些資源安全上的保證,當然java沒有析構函數。比如某些網絡應用,包裝了socket,然而必須的accept,listen,connect,read,write還是需要你自己去調用,只不過調用方式有所變化而已;更麻煩的是處理錯誤,可能的錯誤你必須完全接管,那就需要對問題本身有很深入的了解。基于對象讓你不容易犯錯誤,但是不能改變對問題本身的理解。于是出現了面向對象。 繼承,多態只是它的特點而已,一種表象。而關鍵優越性在于它可以改變對問題的認識。比如處處可見的畫圖的例子,p.Draw(),就能畫出一個形狀,都是Draw()方法,但是可以根據p的不同,動態選擇。無可否認,這個是多態性的優越性的例子。然而繼承又如何呢,可以這樣說,如果不使用多態,繼承就沒有意義了。因為沒有多態,繼承事實上導致了較高層次的包裝而已,與基于對象相同,它不能改變對問題本身的理解。很多時候繼承被包裹所代替,COM的對象重用,就是典型的包裹,不過它叫聚集而已。類層次越深管理越困難。 面向對象提供了極大的靈活性,然而作為一個概念,外延太豐富,反而不容易把握。看看JFC的文檔,實在太靈活了,感覺上這樣那樣幾個東西拼合起來,窗口就可以做成了。事實卻不是如此,你必須去了解layer,了解listener,了解很多東西,然后按照固定的規則進行拼裝才能達到效果。簡單說,看看javadoc的JFC文檔,很難學會如何去實現一個可用的窗口應用。這一點明顯比不上VB,其實這就和使用面向對象方法是為了接口易用性這一個基本原則背離了。外延被擴大化到難以接受的規模,這是使用面向對象方法很容易犯的毛病。而設計模式提供了一些方法緩和這些矛盾,比如用靜態函數創建對象,私有構造,使得對象不能被任意創建,這就大大壓縮了這些對象的外延。簡單看看MessageDigest,可能在內部有md2,md4,md5,sha1的類供我創建對象,但是這些我都不讓你看到,你只要知道一個MessageDigest就足夠了,免得產生誤會。 面向對象: OO=Objects+Classes+Inheritance + Communication With messages 那還是教科書上說的, 多態,解釋就是一個方法被多次構造,,經常出現在,繼承關系類(抽象類,接口) 回憶一下接口使用 interface I_Test{ public void Print (){} } class C_A implment I_Test{ public void Print(){ System.out.println("C_A")} } class C_B implment I_Test{ public void Print(){System.out.println("C_B")} } 再來看看class Test{ public void main(){ I_Test i= new C_A(); i.Print(); //打印出C_A i= new C_B(); i.Print();//打印出C_B } //,"多態性是站在類的角度完成了接口與實現的分離",多態調用Print()方法,不知道能不能解釋這句話,個人是這樣一來理解的。 我個人認為“多態”不單是對父子類,接口,抽象類的理解。。關鍵還是要對 protect,private正確使用中去體味。 這樣才能更好隔離,綜合使用多態才會清晰。 接口可以允許我們為一個類如何實現創建一個好的布局,這是因為接口給我們保證,當許多 相同的一個方法名,但要實現不同的功能的時候,也就是重載,這也多態中的一種。我覺得是多個類的內容結構想似,這時可以抽象出一個接口,這種實現這些類的時候就會自動繼承接口的方法,類的實現簡單的重寫一下接口的內容就好了。 |
|