<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    struggleboy

    Java初學者

    初學者應該懂的幾個問題

    對于這個系列里的問題,每個學 Java 的人都應該搞懂。當然,如果只是學 Java 玩玩就無所謂了。如果你認為自己已經超越初學者了,卻不很懂這些問題,請將你自己重歸初學者行列。內容均來自于 CSDN 的經典老貼。

    問題一: 我聲明了什么!

    String s = "Hello world!";

    許多人都做過這樣的事情,但是,我們到底聲明了什么?回答通常是:一個 String ,內容是 “Hello world!” 。這樣模糊的回答通常是概念不清的根源。如果要準確的回答,一半的人大概會回答錯誤。
    這個語句聲明的是一個指向對象的引用,名為 “s” ,可以指向類型為 String 的任何對象,目前指向 "Hello world!" 這個 String 類型的對象。這就是真正發生的事情。我們并沒有聲明一個 String 對象,我們只是聲明了一個只能指向 String 對象的引用變量。所以,如果在剛才那句語句后面,如果再運行一句:

    String string = s;

    我們是聲明了另外一個只能指向 String 對象的引用,名為 string ,并沒有第二個對象產生, string 還是指向原來那個對象,也就是,和 s 指向同一個對象。

    問題二: "==" equals 方法究竟有什么區別?

    ==
    操作符專門用來比較變量的值是否相等。比較好理解的一點是:
    int a=10;
    int b=10;
    a==b 將是 true
    但不好理解的地方是:
    String a=new String("foo");
    String b=new String("foo");
    a==b 將返回 false

    根據前一帖說過,對象變量其實是一個引用,它們的值是指向對象所在的內存地址,而不是對象本身。 a b 都使用了 new 操作符,意味著將在內存中產生兩個內容為 "foo" 的字符串,既然是 兩個 ,它們自然位于不同的內存地址。 a b 的值其實是兩個不同的內存地址的值,所以使用 "==" 操作符,結果會是 false 。誠然, a b 所指的對象,它們的內容都是 "foo" ,應該是 相等 ,但是 == 操作符并不涉及到對象內容的比較。
    對象內容的比較,正是 equals 方法做的事。

    看一下 Object 對象的 equals 方法是如何實現的:
    boolean equals(Object o){

    return this==o;

    }
    Object
    對象默認使用了 == 操作符。所以如果你自創的類沒有覆蓋 equals 方法,那你的類使用 equals 和使用 == 會得到同樣的結果。同樣也可以看出, Object equals 方法沒有達到 equals 方法應該達到的目標:比較兩個對象內容是否相等。因為答案應該由類的創建者決定,所以 Object 把這個任務留給了類的創建者。

    看一下一個極端的類:
    Class Monster{
    private String content;
    ...
    boolean equals(Object another){ return true;}

    }
    我覆蓋了 equals 方法。這個實現會導致無論 Monster 實例內容如何,它們之間的比較永遠返回 true

    所以當你是用 equals 方法判斷對象的內容是否相等,請不要想當然。因為可能你認為相等,而這個類的作者不這樣認為,而類的 equals 方法的實現是由他掌握的。如果你需要使用 equals 方法,或者使用任何基于散列碼的集合( HashSet,HashMap,HashTable ),請察看一下 java doc 以確認這個類的 equals 邏輯是如何實現的。

    問題三: String 到底變了沒有?

    沒有。因為 String 被設計成不可變 (immutable) 類,所以它的所有對象都是不可變對象。請看下列代碼:

    String s = "Hello";
    s = s + " world!";

    s
    所指向的對象是否改變了呢?從本系列第一篇的結論很容易導出這個結論。我們來看看發生了什么事情。在這段代碼中, s 原先指向一個 String 對象,內容是 "Hello" ,然后我們對 s 進行了 + 操作,那么 s 所指向的那個對象是否發生了改變呢?答案是沒有。這時, s 不指向原來那個對象了,而指向了另一個 String 對象,內容為 "Hello world!" ,原來那個對象還存在于內存之中,只是 s 這個引用變量不再指向它了。
    通過上面的說明,我們很容易導出另一個結論,如果經常對字符串進行各種各樣的修改,或者說,不可預見的修改,那么使用 String 來代表字符串的話會引起很大的內存開銷。因為 String 對象建立之后不能再改變,所以對于每一個不同的字符串,都需要一個 String 對象來表示。這時,應該考慮使用 StringBuffer 類,它允許修改,而不是每個不同的字符串都要生成一個新的對象。并且,這兩種類的對象轉換十分容易。
    同時,我們還可以知道,如果要使用內容相同的字符串,不必每次都 new 一個 String 。例如我們要在構造器中對一個名叫 s String 引用變量進行初始化,把它設置為初始值,應當這樣做:
    public class Demo {
    ??private String s;
    ??...
    ??public Demo {
    ????s = "Initial Value";
    ??}
    ??...
    }
    而非
    s = new String("Initial Value");
    后者每次都會調用構造器,生成新對象,性能低下且內存開銷大,并且沒有意義,因為 String 對象不可改變,所以對于內容相同的字符串,只要一個 String 對象來表示就可以了。也就說,多次調用上面的構造器創建多個對象,他們的 String 類型屬性 s 都指向同一個對象。
    上面的結論還基于這樣一個事實:對于字符串常量,如果內容相同, Java 認為它們代表同一個 String 對象。而用關鍵字 new 調用構造器,總是會創建一個新的對象,無論內容是否相同。
    至于為什么要把 String 類設計成不可變類,是它的用途決定的。其實不只 String ,很多 Java 標準類庫中的類都是不可變的。在開發一個系統的時候,我們有時候也需要設計不可變類,來傳遞一組相關的值,這也是面向對象思想的體現。不可變類有一些優點,比如因為它的對象是只讀的,所以多線程并發訪問也不會有任何問題。當然也有一些缺點,比如每個不同的狀態都要一個對象來代表,可能會造成性能上的問題。所以 Java 標準類庫還提供了一個可變版本,即 StringBuffer

    問題四: final 關鍵字到底修飾了什么?

    final
    使得被修飾的變量 " 不變 " ,但是由于對象型變量的本質是 引用 ,使得 不變 也有了兩種含義:引用本身的不變,和引用指向的對象不變。

    引用本身的不變:
    final StringBuffer a=new StringBuffer("immutable");
    final StringBuffer b=new StringBuffer("not immutable");
    a=b;//
    編譯期錯誤

    引用指向的對象不變:
    final StringBuffer a=new StringBuffer("immutable");
    a.append(" broken!"); //
    編譯通過

    可見, final 只對引用的 ”( 也即它所指向的那個對象的內存地址 ) 有效,它迫使引用只能指向初始指向的那個對象,改變它的指向會導致編譯期錯誤。至于它所指向的對象的變化, final 是不負責的。這很類似 == 操作符: == 操作符只負責引用的 相等,至于這個地址所指向的對象內容是否相等, == 操作符是不管的。

    理解 final 問題有很重要的含義。許多程序漏洞都基于此 ----final 只能保證引用永遠指向固定對象,不能保證那個對象的狀態不變。在多線程的操作中 , 一個對象會被多個線程共享或修改,一個線程對對象無意識的修改可能會導致另一個使用此對象的線程崩潰。一個錯誤的解決方法就是在此對象新建的時候把它聲明為 final ,意圖使得它 永遠不變 。其實那是徒勞的。

    問題五: 到底要怎么樣初始化!

    本問題討論變量的初始化,所以先來看一下 Java 中有哪些種類的變量。
    1.
    類的屬性,或者叫值域
    2.
    方法里的局部變量
    3.
    方法的參數

    對于第一種變量, Java 虛擬機會自動進行初始化。如果給出了初始值,則初始化為該初始值。如果沒有給出,則把它初始化為該類型變量的默認初始值。

    int
    類型變量默認初始值為 0
    float
    類型變量默認初始值為 0.0f
    double 類型變量默認初始值為 0.0
    boolean
    類型變量默認初始值為 false
    char
    類型變量默認初始值為 0(ASCII )
    long
    類型變量默認初始值為 0
    所有對象引用類型變量默認初始值為 null ,即不指向任何對象。注意數組本身也是對象,所以沒有初始化的數組引用在自動初始化后其值也是 null

    對于兩種不同的類屬性, static 屬性與 instance 屬性,初始化的時機是不同的。 instance 屬性在創建實例的時候初始化, static 屬性在類加載,也就是第一次用到這個類的時候初始化,對于后來的實例的創建,不再次進行初始化。這個問題會在以后的系列中進行詳細討論。

    對于第二種變量,必須明確地進行初始化。如果再沒有初始化之前就試圖使用它,編譯器會抗議。如果初始化的語句在 try 塊中或 if 塊中,也必須要讓它在第一次使用前一定能夠得到賦值。也就是說,把初始化語句放在只有 if 塊的條件判斷語句中編譯器也會抗議,因為執行的時候可能不符合 if 后面的判斷條件,如此一來初始化語句就不會被執行了,這就違反了局部變量使用前必須初始化的規定。但如果在 else 塊中也有初始化語句,就可以通過編譯,因為無論如何,總有至少一條初始化語句會被執行,不會發生使用前未被初始化的事情。對于 try-catch 也是一樣,如果只有在 try 塊里才有初始化語句,編譯部通過。如果在 catch finally 里也有,則可以通過編譯。總之,要保證局部變量在使用之前一定被初始化了。所以,一個好的做法是在聲明他們的時候就初始化他們,如果不知道要出事化成什么值好,就用上面的默認值吧!

    其實第三種變量和第二種本質上是一樣的,都是方法中的局部變量。只不過作為參數,肯定是被初始化過的,傳入的值就是初始值,所以不需要初始化。

    問題六: instanceof 是什么東東?

    instanceof
    Java 的一個二元操作符,和 == > < 是同一類東東。由于它是由字母組成的,所以也是 Java 的保留關鍵字。它的作用是測試它左邊的對象是否是它右邊的類的實例,返回 boolean 類型的數據。舉個例子:

    String s = "I AM an Object!";
    boolean isObject = s instanceof Object;

    我們聲明了一個 String 對象引用,指向一個 String 對象,然后用 instancof 來測試它所指向的對象是否是 Object 類的一個實例,顯然,這是真的,所以返回 true ,也就是 isObject 的值為 True
    instanceof
    有一些用處。比如我們寫了一個處理賬單的系統,其中有這樣三個類:

    public class Bill {//
    省略細節 }
    public class PhoneBill extends Bill {//
    省略細節 }
    public class GasBill extends Bill {//
    省略細節 }

    在處理程序里有一個方法,接受一個 Bill 類型的對象,計算金額。假設兩種賬單計算方法不同,而傳入的 Bill 對象可能是兩種中的任何一種,所以要用 instanceof 來判斷:

    public double calculate(Bill bill) {
    ??if (bill instanceof PhoneBill) {
    ????//
    計算電話賬單
    ??}
    ??if (bill instanceof GasBill) {
    ????//
    計算燃氣賬單
    ??}
    ??...
    }
    這樣就可以用一個方法處理兩種子類。

    然而,這種做法通常被認為是沒有好好利用面向對象中的多態性。其實上面的功能要求用方法重載完全可以實現,這是面向對象變成應有的做法,避免回到結構化編程模式。只要提供兩個名字和返回值都相同,接受參數類型不同的方法就可以了:

    public double calculate(PhoneBill bill) {
    ??//
    計算電話賬單
    }

    public double calculate(GasBill bill) {
    ??//
    計算燃氣賬單
    }

    所以,使用 instanceof 在絕大多數情況下并不是推薦的做法,應當好好利用多態。

    posted on 2006-12-16 22:37 struggleboy 閱讀(230) 評論(0)  編輯  收藏


    只有注冊用戶登錄后才能發表評論。


    網站導航:
    博客園   IT新聞   Chat2DB   C++博客   博問  
     
    主站蜘蛛池模板: 95老司机免费福利| 亚洲国产精品99久久久久久| a级毛片毛片免费观看久潮| 亚洲午夜爱爱香蕉片| 免费视频精品一区二区| 亚洲高清视频一视频二视频三| 色网站在线免费观看| 亚洲?V无码乱码国产精品| 免费在线观看一区| 国产亚洲?V无码?V男人的天堂| 在线观看免费黄网站| 亚洲无线电影官网| 韩国免费一级成人毛片| 亚洲另类无码一区二区三区| 亚洲成?v人片天堂网无码| j8又粗又长又硬又爽免费视频| 国产亚洲精品自在久久| 67194成手机免费观看| 亚洲最大的成人网| 午夜亚洲国产成人不卡在线| 国产午夜无码片免费| 色婷婷六月亚洲婷婷丁香| 免费可以看黄的视频s色| 亚洲AV无码一区二区大桥未久| 免费a级毛片网站| 中文字幕久精品免费视频| 亚洲综合色一区二区三区小说| 在线观看免费污视频| 四虎影视在线看免费观看| 亚洲爱情岛论坛永久| 一二三四免费观看在线视频中文版| 亚洲色在线无码国产精品不卡 | 伊在人亚洲香蕉精品区麻豆| 国产精品成人免费观看| 亚洲网站免费观看| 亚洲福利在线播放| 1000部啪啪毛片免费看| 国产精品亚洲а∨无码播放不卡| 国产精品亚洲成在人线| 成人免费毛片观看| 青青操视频在线免费观看|