• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            chenglong7997

            java重載重寫陷阱(2)

            隱藏(hide):子類的某個字段、靜態方法、成員內部類與其父類的具有相同名字(對于靜態方法還需要相同的參數列表),此時父類對應的字段、靜態方法、成員內部類就被隱藏了。

            舉個例子,天鵝(Swan)是會飛的,而丑小鴨(UglyDuck)小時候是不會飛的,看看下面的代碼,看看能夠打印出什么。

            1. class Swan {  
            2.     public static void fly() {  
            3.         System.out.println("swan can fly ...");  
            4.     }  
            5. }  
            6.  
            7. class UglyDuck extends Swan {     
            8.     public static void fly() {  
            9.         System.out.println("ugly duck can't fly ...");  
            10.     }  
            11. }  
            12.  
            13. public class TestFly {    
            14.     public static void main(String [] args) {  
            15.         Swan swan = new Swan();  
            16.         Swan uglyDuck = new UglyDuck();  
            17.         swan.fly();  
            18.         uglyDuck.fly();  
            19.     }  

            按道理的話,我們認為應該是輸出兩句不同的結果,因為我們可能認為 UglyDuck 繼承了 Swan 并且“重寫”了 fly() 方法,而且在 main() 方法中 Swan uglyDuck = new UglyDuck();  也表明了 uglyduck 實際上是 UglyDuck 類型的,因此構成了多態行為。

            其實,運行結果是兩句“swan can fly ...”,為什么會這樣子?原因有下:

            1、父類 Swan 中的 static 靜態方法 fly() 是不能被重寫的,上一段我對重寫二字用了雙引號;

            2、盡管子類 UglyDuck 中的 fly() 方法與父類中的有一致的參數列表,但是對于 static 方法來說,這叫隱藏(hide),而不是重寫(override);

            3、對于 static 方法,根本不存在像多態那樣的動態分派機制,JVM 不會根據對象引用的實際類型來調用對應的重寫方法。這一點在個例子中是最重要的。

            對于 static 方法,我們稱之為類方法,不是實例方法,對 static 方法的調用直接用所屬類名加個點就行,如 UglyDuck.fly() 。而實例方法就不得不使用對象引用來獲得其可訪問方法的調用權。在上面的例子 main() 中的 uglyDuck.fly() 語句,JVM 根本據不會去判斷 uglyDuck 引用的究竟是什么類型,既然調用的是 fly() 方法,那么 JVM 只會根據 uglyDuck 的聲明類型(即 Swan 類)去獲得該 static 方法的調用。根本就談不上多態…

            這就說明,最好避免用對象引用的方式來訪問一個 static 方法。此外,別以為在繼承關系上的父類、子類只要方法名、參數列表一致就是重寫(override)而構成多態,其實還得看看父類中的方法有沒有被什么修飾符聲明(在這個例子中是 static 修飾的)。再如 final 修飾符的方法則表明不可被子類重寫,即方法名、參數列表不能和父類完全一致。在我看來,這一類修飾符就表明了方法、變量、字段等特有的性質,或者是身份。

            對于隱藏(hide),實際上是為了使得父類中的該方法、字段、內部類等不允許再被下一級繼承樹的子子類所繼承。說起隱藏,我想起《代碼大全 2》當中剛好看過的內容,作者認為把握住信息隱藏的原則來思考軟件構建要優于面向對象原則。有點抽象難懂,書中還講到封裝、模塊化和抽象等幾個概念,建議看看,我也要回過頭去多啃啃這些抽象概念。

            要修改上面代碼,只需要去掉兩個 static 則可,那就構成多態了。《Java 解惑》中其他謎題還講到多種該注意的地方,可以看看。

            小結:

            1、注意掌握重寫(override)與隱藏(hide)的異同點:相同點就是兩者都是相對于繼承樹中父類、子類來說,而不同點就是其目的以及所造成的效果。別把重寫和隱藏混淆在一起了;

            2、對于 static 方法,要避免用具體的對象引用來調用,而應該簡單的用其所屬類名進行調用即可。

             遮蔽(shadow):其實就是平時我們可能遇到的窄作用域的變量名、方法名、類名等將其他相同名字的變量、方法、類屏蔽掉的現象。

            例如,最常見的就是局部變量將類實例變量屏蔽了。其實,遮蔽這個詞我之前好像也沒什么印象,不過作用域屏蔽這種情況我們大多應該會避免的了,因為課堂上、教材上對于變量作用域的內容已經講解過了,盡管沒有這么一個術語。此時如果想要獲得被遮蔽實體的引用、調用,則只能通過完整的限定名去實現了。不過有一些情況可能是根本就引用不到的,被屏蔽得太嚴密了。

             遮掩(obscure):一個變量可以遮掩具有相同名字的一個類,只要它們都在同一個范圍內:如果這個名字被用于變量與類型都被許可的范圍,那么它將引用到變量上。相似地,一個變量名或一個類名可以遮掩一個包。遮掩是唯一一種兩個名字位于不同的名字空間的名字重用形式,這些名字空間包括:變量、包、方法或類。如果一個類型或一個包被遮掩了,那么你不能通過其簡單名引用到它,除非是在這樣一個上下文環境中,即語法只允許在其名字空間中出現一種名字。遵守命名習慣就可以極大地消除產生遮掩的可能性。

            其實,遮掩這個術語我更是完全沒聽過了,上面這一段是從《Java 解惑》中引用過來的。我覺得,如果代碼是一個人所寫,或者團隊中大家都遵守了一定的命名規范,而且也各自分配了一定職責,那么遮掩這種情況應該是可以避免的。同樣,需要使用完全限定名來引用被遮掩掉的實體,如下:

            用前面例子的代碼大概就是這種情況:

            1. public class TestFly {    
            2.     // 如此變量名  
            3.     static String System = "system";  
            4.     public static void main(String [] args) {  
            5.  
            6. //      String System = "hao";    
            7.         // 編譯不通過  
            8. //      System.out.println("No");  
            9.         // 編譯通過  
            10.         java.lang.System.out.println("OK");  
            11.     }  
            12. }

            小結:

            1、我覺得,在文章標題當中的五個名詞當中,尤為前面三個最為重要,陷阱炸彈也多多,而且文中所講僅僅是那么一丁點兒相關的,大量更細節的還得慢慢發現;

            2、就算后面兩個名詞,也就是這兩種情況不常見,但了解一下記在腦里還是不錯的,畢竟為自己增加了專業詞匯量;

            3、最后,就是建議各位也看看《Java 解惑》然后也告訴我一些炸彈型陷阱之類的,呵呵...學習快樂!加油!

            本文出自 “螞蟻” 博客,請務必保留此出處http://haolloyin.blog.51cto.com/1177454/372911

            posted on 2012-04-11 14:00 Snape 閱讀(303) 評論(0)  編輯 收藏 引用 所屬分類: Java

            導航

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            統計

            常用鏈接

            留言簿

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            my

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久精品国产WWW456C0M| 久久中文字幕无码专区| 亚洲AV乱码久久精品蜜桃| 久久久久久精品久久久久| 777午夜精品久久av蜜臀| www.久久热.com| 精品国产乱码久久久久久浪潮| 综合久久精品色| 久久精品国产91久久麻豆自制 | 人妻少妇精品久久| 亚洲中文字幕无码一久久区| 精品免费tv久久久久久久| 性做久久久久久免费观看| 99久久人妻无码精品系列| 久久久久久国产a免费观看黄色大片| 日韩精品久久无码人妻中文字幕| 久久国产成人午夜aⅴ影院| 熟妇人妻久久中文字幕| 亚洲美日韩Av中文字幕无码久久久妻妇 | 精品免费久久久久久久| 中文成人无码精品久久久不卡| 国产成人久久精品区一区二区| 国产69精品久久久久久人妻精品| 国产精久久一区二区三区| 久久精品国产亚洲av水果派| 国产免费久久精品99re丫y| 久久久综合香蕉尹人综合网| 久久精品成人国产午夜| 久久福利青草精品资源站| 麻豆亚洲AV永久无码精品久久| 久久午夜无码鲁丝片秋霞 | 婷婷国产天堂久久综合五月| 精品久久久久久国产三级| 91精品日韩人妻无码久久不卡 | 亚洲欧美伊人久久综合一区二区| 国产精品久久久久久久午夜片 | 2020久久精品国产免费| 国产精品一区二区久久不卡| 国产精品9999久久久久| 久久精品免费一区二区三区| 国产精品一区二区久久|