1. 程式人生 > 實用技巧 >Java接地氣日常編碼技巧

Java接地氣日常編碼技巧

Effective Java。Java名著,必讀。如果能嚴格遵從本文的原則,以編寫API的質量來苛求自己的程式碼,會大大提升編碼素質。

以下內容只記錄了我自己整理的東西,還是建議讀原文。為了聚焦知識點,一些說明故意忽略掉了。相當於是一篇摘要。


1、考慮用靜態工廠方法替代建構函式

例子:

Integer.valueOf(“1”)、Boolean.valueOf(“true”)等。

優勢:

  • 可讀性高(方法名)
  • 效能(不一定建立物件)
  • 靈活性高

下面針對三個優勢進行一些解讀。

可讀性高

new Point(x,y)和Point.at(x,y)、Point.origin()。建構函式只能看出兩個引數,不知其意,後者更易理解。

效能

在某些情況下,可以事先進行例項化一些物件,呼叫時直接呼叫即可,不需要進行改變。比如,Boolean。

public final class Boolean implements Serializable, Comparable<Boolean> {
    // 預先設定兩個物件
    public static final Boolean TRUE = new Boolean(true);
    public static final Boolean FALSE = new Boolean(false);

    public Boolean(boolean var1) {
        this.value = var1;
    }

    public Boolean(String var1) {
        this(parseBoolean(var1));
    }

    // 工廠方法
    public static Boolean valueOf(boolean var0) {
        return var0?TRUE:FALSE;    // 返回預先設定的物件,而不是建立物件
    }
    // 工廠方法
    public static Boolean valueOf(String var0) {
        return parseBoolean(var0)?TRUE:FALSE;
    }
    // ... other code
}

靈活性高

可根據具體情況,返回子類。相當於更強大的工廠。直接從父類獲取到子類。尤其適用於工具類(提供各種API)。例子:Collections。

public class Collections {
    // 私有,典型工廠
    private Collections() {
    }

    public static final List EMPTY_LIST = new EmptyList<>();
    // 工廠方法
    public static final <T> List<T> emptyList() {
        return (List<T>) EMPTY_LIST;
    }
    private static class EmptyList<E> extends AbstractList<E> implements RandomAccess, Serializable {
    // code
    }

    // 工廠方法
    public static <E> List<E> checkedList(List<E> list, Class<E> type) {
    // 根據具體情況,獲取相應子類
        return (list instanceof RandomAccess ?
                new CheckedRandomAccessList<>(list, type) :
                new CheckedList<>(list, type));
    }

    // 子類1
    static class CheckedRandomAccessList<E> extends CheckedList<E> implements RandomAccess {
        CheckedRandomAccessList(List<E> list, Class<E> type) {
            super(list, type);
        }

        public List<E> subList(int fromIndex, int toIndex) {
            return new CheckedRandomAccessList<>(
                    list.subList(fromIndex, toIndex), type);
        }
    }

    // 子類2
    static class CheckedList<E> extends CheckedCollection<E> implements List<E> {
    // code
    }
}

《犬小哈教程》

2、多個建構函式時,考慮使用構造器

尤其在進行Android開發時,會碰到這種情況。通常是一個物件,具有多個成員變數可能需要初始化,常規方法,需要提供大量建構函式。例如:

// 非Android中的AlertDialog,便於說明問題,舉個例子
public class AlertDialog {
    private int width;
    private int height;
    private String title;
    private String confirmText;
    private String denyText;

    private AlertDialog(){}
    public AlertDialog(int width, int height){    // 空白的警告框
         AlertDialog(width,height,null);
    }

    // 帶標題的警告框
    public AlertDialog(int width, int height, String title){    // 帶標題的警告框
        AlertDialog(width, height, title, "確定");
    }

    // 帶標題的警告框,有確定按鈕
    public AlertDialog(int width, int height, String title, String confirm){   
        AlertDialog(width, height, title, confirm, null);
    }

    // 帶標題的警告框,有確定按鈕,取消按鈕
    public AlertDialog(int width, int height, String title, String confirm, String denyText){
        // set every thing.
    }
}

有多種樣式的警告框,為了呼叫方便,必須提供多個建構函式。否則使用者在呼叫時,只能使用完整建構函式,容易犯錯且無法進行閱讀。極不靈活。如果採用另外一種方式,則可以解決,但會花費很多經歷處理併發的情況:

// 非Android中的AlertDialog,便於說明問題,舉個例子
public class AlertDialog {
    private int width;
    private int height;
    private String title;
    private String confirmText;
    private String denyText;

    public AlertDialog(){}// 空白的建構函式
   
    public void setWidth(int width){
        this.width = width;
    }
    // 其他set方法
}

呼叫時,通過呼叫各個引數的set方法進行設定。問題來了:

  1. 併發
  2. 無法進行引數校驗。例如,只建立了物件,設定了標題,卻沒有尺寸,相當於建立了一個沒有尺寸的警告框。

在Android中,大量的控制元件都使用了構造器Builder。

// 非Android中的AlertDialog,便於說明問題,舉個例子
public class AlertDialog {
    private int width;
    private int height;
    private String title;
    private String confirmText;
    private String denyText;

    // private
    private AlertDialog(){}

    // Builder中使用
    protected AlertDialog(Builder b){
        width = b.width;
        height = b.height;
        // .....
        if(width==0||height==0) throws new Exception("size must be set");
    }

    // 構造器
    public static class Builder {
        private int width;
        private int height;
        private String title;
        private String confirmText;
        private String denyText;

        // 注意:返回的Builder。
        public Builder setTitle(String title) {
            this.title = title;
            return this;
        }
        // 其他set...
        
        public AlertDialog build(){
            return AlertDialog(this);
        }
    }
}

於是,可以根據相應需求,進行相應設定,並在AlertDialog真正構造時,進行引數校驗。就像這樣:

new AlertDialog.Builder().setTitle("提示").build();

上述例子,會成功丟擲異常。

3、用私有化構造器或者列舉型強化Singleton。

Singleton指最多會被例項化一次的類。通常情況下,以前的做法是沒有問題的。但是在某些高階情況,通過使用反射的相關知識訪問private的建構函式,破壞Singleton。

public class Elvis{
    // 注意,公有final物件
    public static final Elvis INSTANCE = new Elvis();
    private Elvis(){}
}

另一種情況,在序列化的過程中,反序列化得到的物件已經不再是以前的物件(破壞了Singleton),這種情況下,可以通過單元素列舉型處理。

public enum Elvis{
    INSTANCE;
    // some methods
}

4、通過私有化構造器強化不可例項化的能力

有一些工具類,僅僅是提供一些能力,自己本身不具備任何屬性,所以,不適合提供建構函式。然而,缺失建構函式編譯器會自動新增上一個無參的構造器。所以,需要提供一個私有化的建構函式。為了防止在類內部誤用,再加上一個保護措施和註釋。

public class Util{
    private Util(){
        // 丟擲異常,防止內部誤呼叫
        throw new AssertionError();
    }
}

弊端是無法對該類進行繼承(子類會呼叫super())。

5、避免建立不必要的物件

  • 物件的重用
  • 昂貴的物件,使用物件池
  • 廉價的物件,慎用物件池。現代JVM對廉價物件的建立和銷燬非常快,此時不適於使用物件池。

6、消除過期的物件引用

以下三種情況可能會造成記憶體洩露:

  • 自己管理的記憶體(陣列長度減小後,pop出的物件容易導致記憶體洩漏)
  • 快取
  • 監聽和回撥

自己管理的記憶體

對於自己管理的記憶體要小心,比如:

public class Stack{
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;
    
    public Stack(){
         elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(Object e){
        ensureCapacity();
        elements[size++]=e;    // allocate新的堆記憶體和棧記憶體
    }

    public Object pop(){
        if(size==0) throw new EmptyStackException();
        return element[--size];    // pop出element[size],該物件不再有效。記憶體洩漏原因。
    }
    
    private void ensureCapacity(){
        if(elements.length==size)
            elements = Arrays.copyOf(elements, 2*size+1);
    }
}

彈出的物件不再有效,但JVM不知道,所以會一直保持該物件,造成記憶體洩露。

解決:

    public Object pop(){
        if(size==0) throw new EmptyStackException();
        elements[size] = null;        // 等待回收
        return element[--size];
    }

快取

快取的物件容易被程式設計師遺忘,需要設定機制來維護快取,例如不定期回收不再使用的快取(使用定時器)。某些情況下,使用WeakHashMap可以達到快取回收的功效。注,只有快取依賴於外部環境,而不是依賴於值時,WeakHashMap才有效。

監聽或回撥

使用監聽和回撥要記住取消註冊。確保回收的最好的實現是使用弱引用(weak reference),例如,只將他們儲存成WeakHashMap的鍵。

7、避免顯示呼叫GC

Java的GC有強大的回收機制,可以簡單的記住:不要顯示呼叫finalizer。可以這樣理解:

jvm是針對具體的硬體設計的,然而程式卻不是針對具體硬體設計的,所以,java程式碼無法很好的解決gc問題(因為他具有平臺差異化)。另外,finalizer的效能開銷也非常大,從這個角度上考慮也不應該使用它。

8、覆蓋equals方法請遵守通用約定

  • 自反性。x.equals(x) == true
  • 對稱性。當前僅當y.equals(x)true時,x.equals(y)true
  • 傳遞性。if(x.equals(y)&&y.equals(z)),y.equals(z)==true
  • 一致性。
  • 非空性。x.equals(null)==false

9、覆蓋equals方法時總要覆蓋hashCode

為了保證基於雜湊的集合使用該類(HashMap、HashSet、HashTable),同時,也是Object.hashCode的通用約定,覆蓋equals方法時,必須覆蓋hashCode。

10、始終覆蓋toString

Object的toString方法的通用約定是該物件的描述。注意覆蓋時,如果有格式,請備註或者嚴格按照格式返回。

11、謹慎覆蓋clone

12、考慮實現Comparable介面

13、使類和成員的可訪問性最小化

目的是解耦。簡單來講,使用修飾符的優先順序從大到小,private>protected>default(預設)>public。如果在設計之初,設計為private修飾符後,在之後的編碼過程如果不得不擴大其作用於,應該先檢查是否設計的確如此。

子類覆蓋超類,不允許訪問級別低於超類的訪問級別。(超類的protected,子類覆蓋後不能改為default)。

成員變數決不允許是公有的。一旦設定為公有,則放棄了對他處理的能力。這種類並不是執行緒安全的。即使是final的,也不允許。除非希望通過public static final來暴露常量。成員變數總是需要使用setter和getter來維護。有一個例外:長度非零的陣列。這是安全漏洞的一個根源。

// 安全漏洞!此處的陣列,並不是不可變的
public static final Thing[] VALUES = {...}

改進:

private static final Thing[] PRIVATE_VALUES = {...}
// 此時獲取到的才是“常量”
public static final List<Thing> VALUS = 
    Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES))

另一種:

private static final Thing[] PRIVATE_VALUES = {...}
// 此時獲取到的才是“常量”
public static final Thing[] values(){
    return PRIVATE_VALUES.clone();
}

14、在公有類中使用訪問方法而非公有成員變數(類似13)

15、使可變性最小化

16、複合優先於繼承

繼承有利於程式碼複用,但是儘可能不要進行跨包的繼承。包內的繼承是優秀的設計方式,一個包裡的檔案處在同一個程式設計師的控制之下。但是繼承有其侷限性:子類依賴於超類。超類一旦發生更改,將可能破壞子類。並且,如果超類是有缺陷的,子類也會得“遺傳病”。

複合,即不擴充套件已有的類,而是在的類中新增一個現有類的。相當於現有類作為一個組建存在於新類中。如此,將只會用到需要用到的東西,而不表現現有類所有的方法和成員變數。新類也可以稱為“包裝類”,也就是設計模式中的Decorate模式。

17、要麼就為繼承而設計,並提供文件說明,要麼就禁止繼承

18、介面優於抽象類

19、介面只用於定義型別

20、類層次優先於標籤類

21、用函式物件表示策略

函式引數可以傳入類似listener的物件,目的是使用listener中的方法。如果使用匿名的引數,每一次呼叫會建立新的物件。可以將listener宣告為成員變數,每次都複用同一個物件,並且可以使用靜態域(static變數)。比如String類的CASE_INSENSITIVE_ORDER域。

22、優先考慮靜態類成員

巢狀類的目的應該只是為了他的外圍類提供服務,如果以後還可能用於其他環境中,則應該設計為頂層類。靜態類相當於一個普通的外部類,只是恰好宣告在了一個類內部。通常的使用者是:Calculator.Operation.PLUS等。和普通類的區別只是,在PLUS前,有了2個字首,來表明其含義。而非靜態類必須存在於外部類物件中。不要手動在外部建立一個內部非靜態類物件,建立的過程是:instance.New MemberClass()。這非常奇怪。

如果成員類不需要訪問外圍類,則需要新增static,是他成為靜態成員類,否則每個例項都將包含一個額外指向外圍物件的引用。將會影響垃圾回收機制。

23、應指定泛型的具體型別,而不是直接使用原生型別。

例如,應該指定List,而不建議直接使用List。

24、消除非首檢警告

在使用IDE進行編碼時,強大的IDE都會在你編碼過程中提示warning,需要儘可能的消除warning,至少,應該小心這些warning。慎用SuppresWarning,如果IDE提示你可以通過新增該註解解決掉warning,請不要那麼做。如果實在要使用,請添加註釋說明原因。

25、列表優先於陣列

類比泛型,陣列是有一定缺陷的。List和List是沒有關係的,而Sub[]是Super[]的子類。

// Fails at runtime
Object[] objectArray = new Long[1];
objectArray[0] = "I don't fit in";       // throw exception

// won't compile
List<Object> ol = new ArrayList<Long>();   // Incompatible types
ol.add("I don't fit in");

從程式碼中可以看到,使用泛型,會提前發現錯誤。

26、優先考慮泛型

27、優先考慮泛型方法

28、利用有限制萬用字元來提升API的靈活性

PECS,producer-extends,consumer-super。

//public class Stack<E>{
//    public Stack();
//    public void push(E e);
//    public E pop();
//    public boolean isEmpty();
//}

public void pushAll(Iterator<? extends E> src){
    for(E e : src)
        push(e);
}

public void popAll(Collection<? super E> dst){
    while(!isEmpty()){
        dst.add(pop());
    }
}

// Get and Put Principle

所有comparable和comparator都是消費者(Consumer)。

29、優先考慮型別安全的異構容器

30、用enum代替int常量

public enum Apple { FUJI, PIPPIN, GRANNY_SMITH }
public enum Orange { NAVEL, TEMPLE, BLOOD }

列舉型在java中非常強大,當需要一組固定常量時,使用enum比int好很多。比如程式碼可讀性,安全性等。

31、enum用例項域代替序數

// bad solution
public enum Ensemble {
    SOLO, DUET, TRIO, QUARTET, QUINTET, 
    SEXTET, SEPTET, OCTET, NONET, DECTET;

    public int numberOfMusicians() { return ordinal() + 1; }
}
// 

// improvement
public enum Ensemble {
    SOLO(1), DUET(2), TRIO(3), QUARTET(4), QUINTET(5), 
    SEXTET(6), SEPTET(7), OCTET(8), NONET(9), DECTET(10), TRIPLE_QUARTET(12);

    private final int numberOfMusicians;
    Ensemble(int size) { this.numberOfMusicians = size; }
    public int numberOfMusicians() { return numberOfMusicians; }
}

永遠不要像第一種的方式,利用序數訪問enum,需要在建構函式中使用引數來初始化。

32、用EnumSet代替位域

public class Text{
    public static final int STYLE_BOLD                     = 1 << 0;    // 1
    public static final int STYLE_ITALIC                    = 1 << 1;    // 2
    public static final int STYLE_UNDERLINE          = 1 << 2;    // 4
    public static final int STYLE_STRIKETHROUGH = 1 << 3;    // 8

    public void applyStyles(int styles){  
        // ...
    }
}



// 
text.applyStyles(STYLE_BOLD | STYLE_ITALIC);

以上叫做點陣圖法,但是有更好的方案來傳遞多組常量——EnumSet。

public class Text{
    public enum Style { BOLD, ITALIC, UNDERLINE, STRIKETHROUGH }

    // 注意此處,使用的是Set而不是EnumSet
    public void applyStyles(Set<Style> styles){  
        // ...
    }
}



// 
text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC));

33、用EnumMap代替序數索引

任何時候都不要使用enum的ordinal()方法。

34、用介面模擬可伸縮的列舉

35、註解優先於命名模式

36、堅持使用Override註解

38、檢查引數的有效性

公有方法檢查引數,引數異常需要跑出Exception。私有方法利用斷言assertion檢查引數。

39、必要時進行保護性拷貝

假設類的客戶端會盡其所能來破壞這個類的約束條件,因此你必須保護性的設計程式。以下是一個不可變類的設計。

public Period(Date start, Date end){
    this.start  = new Date(start);        // 使用了值的拷貝,沒有使用原物件(指標)
    this.end = new Date(end);
    if(this.start.compareTo(this.end)>0)
        throw new IllegalArgumentException(start + " after " + end)
}

注意:保護性拷貝是在檢查引數之前進行的,防止多執行緒的影響。不要使用clone方法進行保護性拷貝。

以上方法防禦了傳入引數的修改,但是對於get方法獲取到的物件,仍然可以被修改,通過以下方法可以防止這種攻擊。

public Date start(){
    return new Date(start);
}

public Date end(){
    return new Date(end);
}

40、謹慎設計方法簽名

41、慎用過載

42、慎用可變引數

43、返回0長度的陣列或者集合,而不是null

null一般用於表示沒有被初始化或處理,如果方法返回了null,則需要在上層做更多的處理,以防止NPE。

44、為所有匯出的API元素編寫文件註釋

正確的javadoc文件,需要每個被匯出的類、介面、構造器、方法和域之前增加文件註釋。註釋應該是對實現透明的,只需要簡潔的描述它和客戶端之間的約定。並且,還應該附上該方法的副作用。

45、將區域性變數的作用域最小化

46、for-each優先於for迴圈

for-each規避掉了for迴圈的index變數的引用,通常來說它是不必要的——會增加引入錯誤的風險,並且風險一旦發生,很難被發現。不過有三種情況下,無法使用for-each(注:在jdk1.8中已經很好的解決了這些問題)。

  • 過濾
  • 轉換
  • 平行迭代

48、如果需要精確的答案,請避免使用float和double

float和double是執行的二進位制浮點運算,目的是在廣泛數值範圍上使用精確的快速近似計算而設計的。然而他們並沒有提供完全精確的計算(實際應用中,經常會碰到出現x.99999等結果)。尤其是,在進行貨幣計算時,他們並不適用。比如:

System.out.println(1.03-.42);

得到的結果將是:0.610000000001。

為了解決這個問題,需要使用BigDecimal。然而這也有一些問題,相對於普通的運算,它顯得更加麻煩,而且也更慢。通常來說後一個缺點可以忽略,但是前者可能會讓人很不舒服。有一種做法是將需要處理的數值*10(或更多),使用int進行計算,不過需要你自己處理四捨五入等操作。

49、基本型別優先於裝箱基本型別

  • 基本型別只有值,裝箱類具有與他們值不同的同一性。
  • 基本型別只有功能完備的值,裝箱類還具有非功能值:null。所以你可能會碰到NPE
  • 基本型別省空間省時間

50、如果有更精確的型別,請避免使用字串

  • 字串不適合代替其他值的型別。例如:int,boolean等
  • 不適合代替列舉型別(第30條)
  • 不適合聚集型別

51、當心字串連線的效能

操作符“+”可以將多個字串進行連線。但是在大規模使用“+”的情況下,連線n個字串的開銷是n的平房級時間。這是由於字串的不可變性導致的。在這種情況下請使用StringBuilder進行連線。

52、通過介面引用物件

53、介面優先於反射機制

使用反射機制會帶來以下的問題:

  • 喪失了編譯期型別檢查
  • 程式碼笨拙冗長
  • 效能損失

反射基本上只適合用在編寫元件時、程式碼分析器、RPC等場景下使用。在使用反射機制時,如果可能,儘可能只通過反射機制例項化物件,而訪問方法時,使用已知的介面或者超類。

54、謹慎使用JNI

55、謹慎進行優化

很多計算上的過失都被歸咎於效率(沒有必要達到的效率),而不是任何其他原因——甚至包括盲目的做傻事。

——William A. Wulf

不要去計較效率上的一些小小的得失,在97%的情況下,不成熟的優化才是一切問題的根源。

——Donald E. Knuth

在優化方面,我們應該遵守兩條規則:

規則1:不要進行優化。

規則2(僅針對專家):還是不要進行優化——也就是說,在你還沒有絕對清晰的優化方案前,請不要進行優化。

——M. A. Jackson

這些格言比java的出現還要早20年。他們講述了一個關於優化的深刻事實:優化的弊大於利。

要努力編寫好的程式,而不是快的程式。低耦合的重要性遠遠大於效能。當程式編寫得足夠低耦合後,通過工具發現了效能瓶頸的程式碼塊,才可以保證對其的修改不影響任何外部環境。

56、遵守普遍的命名規則

57、只針對異常情況才使用異常

不要嘗試通過異常機制來做正常程式碼應該做的事情,比如,檢查陣列下標。

jvm很少對異常進行優化,因為它只用於不正常的情況。並且,如果你將程式碼放入try-catch程式碼塊,jvm就喪失了本來可以對它進行的優化。

58、對於可恢復的情況使用受檢異常,對於程式設計錯誤的情況使用執行時異常

  • 如果期望呼叫者適當的恢復,則需要使用受檢異常,強迫呼叫者食用try-catch程式碼塊,或者將他們丟擲去
  • 當呼叫發生前提違例——違反約定的情況時,使用執行時異常,這個時候程式已經無法再執行下去了。例如呼叫陣列的-1索引。

58、避免不必要的受檢異常

(其他部分不做筆記記錄)

本文來源:http://r6d.cn/9KG9