【51CTO.com快譯】我在本文中將介紹幾個(gè)錯(cuò)誤，據(jù)我的感受，我們?cè)谟肑ava開發(fā)代碼，尤其是使用集成開發(fā)環(huán)境（IDE）的工具自動(dòng)生成代碼時(shí)經(jīng)常犯這些錯(cuò)誤。

自動(dòng)生成代碼很棒，它讓我們少敲打好多代碼，有助于關(guān)注領(lǐng)域問(wèn)題，而不是關(guān)注樣本代碼的細(xì)枝末節(jié)。然而，有時(shí)候，我們并不認(rèn)真思考IDE為我們生成的代碼，我們留下了應(yīng)該修復(fù)的小瑕疵。我在本文中將逐一介紹這些錯(cuò)誤。

公共域

IDE在默認(rèn)情況下認(rèn)為所有類都是公共類。所以，如果我們要求IntelliJ創(chuàng)建一個(gè)新的類，就會(huì)出現(xiàn)這種情況：

public class MyClass { 
} 

在我看來(lái)，類在默認(rèn)情況下會(huì)有包作用域（package scope），即：

public class MyClass { 
} 

這樣一來(lái)，它們?cè)谒鶎俚陌馐遣豢梢姷?。如果某個(gè)時(shí)候我們需要更改類的域，就要考慮原因，并且做出便利的設(shè)計(jì)決定。如果類在默認(rèn)情況下是公共類，我們就直接拿來(lái)使用，從而增加代碼的耦合性。

要避免這個(gè)問(wèn)題，***的辦法就是在我們的IDE中編輯模板。比如在IntelliJ IDEA中，這個(gè)選項(xiàng)在偏好設(shè)置>編輯器> 文件和代碼模板> 模板>類中。

我們?cè)谀J(rèn)情況下使用包作用域時(shí)的***實(shí)踐之一就是，它將接口創(chuàng)建為公共接口，但是又不暴露其實(shí)現(xiàn)。這樣一來(lái)，接口的客戶根本不知道它們使用的實(shí)現(xiàn)，因?yàn)樗鼈兩踔翢o(wú)法訪問(wèn)它，青睞依賴項(xiàng)注入之類的實(shí)踐。

公共域這方面的另一個(gè)例子是，IntelliJ在默認(rèn)情況下將變量創(chuàng)建為公共：

public static final String CONSTANT = "value"; 

大多數(shù)時(shí)候，變量只被擁有它們的那個(gè)類使用。請(qǐng)注意這個(gè)，或者更改你的模板。

不可變類

這個(gè)細(xì)節(jié)與自動(dòng)生產(chǎn)的代碼沒(méi)有直接關(guān)聯(lián)，但是我們?cè)?9%的時(shí)候忽視了它。通常來(lái)說(shuō)，當(dāng)我們想要設(shè)計(jì)某個(gè)類是不可變類時(shí)，結(jié)果就會(huì)是這樣子：

public class MyImmutableClass { 
 
    private final int id; 
    private final String name; 
 
    public MyImmutableClass(int id, String name) { 
        this.id = id; 
        this.name = name; 
    } 
 
    public int getId() { 
        return id; 
    } 
 
    public String getName() { 
        return name; 
    } 
} 

 私有字段及最終字段，沒(méi)有setter方法，沒(méi)有構(gòu)造函數(shù)初始化。OK，這很好，但是我們遺漏了什么。不妨看看如果我們這么做，會(huì)出現(xiàn)什么情況：

public class MyImmutableDerivedClass extends MyImmutableClass{ 
    public String address; 
    public MyImmutableDerivedClass(int id,  
                                   String name,  
                                   String address) { 
        super(id, name); 
        this.address = address; 
    } 
    public String getAddress() { 
        return address; 
    } 
    public void setAddress(String address) { 
        this.address = address; 
    } 
} 

這第二個(gè)類的實(shí)例（繼承自MyImmutableClass）可以充當(dāng)它的代理，客戶根本不注意，即：

MyImmutableClass myImmutableClass  
 
                = new MyImmutableDerivedClass(1, "name", "address");  

這并不理想，因?yàn)檫@個(gè)派生類不是不可變的！ 解決辦法很簡(jiǎn)單，我們不妨讓不可變類成為最終類：

public final class MyImmutableClass {  
 
    //...  
 
}  

 現(xiàn)在就不可能創(chuàng)建派生類了。

getter和setter方法

我們常常創(chuàng)建擁有所有字段的類，并且在自動(dòng)生成的代碼這股熱潮下，為所有字段添加構(gòu)造函數(shù)、getter方法和setter方法。

我們果真需要這么做嗎？

public class MyClass { 
 
    private Collaborator1 collaborator1; 
    private Collaborator2 collaborator2; 
 
    public MyClass(Collaborator1 collaborator1, 
                   Collaborator2 collaborator2) { 
        this.collaborator1 = collaborator1; 
        this.collaborator2 = collaborator2; 
    } 
 
    public Collaborator1 getCollaborator1() { 
        return collaborator1; 
    } 
 
    public void setCollaborator1(Collaborator1 collaborator1) { 
        this.collaborator1 = collaborator1; 
    } 
 
    public Collaborator2 getCollaborator2() { 
        return collaborator2; 
    } 
 
    public void setCollaborator2(Collaborator2 collaborator2) { 
        this.collaborator2 = collaborator2; 
    } 
} 

一個(gè)類應(yīng)該暴露最少數(shù)量的內(nèi)部細(xì)節(jié)。所以，前面說(shuō)過(guò)一個(gè)類應(yīng)該有包作用域，直到它需要是公共的，現(xiàn)在我要說(shuō)除非需要，否則類不該有g(shù)etter或setter方法。如果出現(xiàn)這種情況，就要想想這是不是***決定，或者你的設(shè)計(jì)中有沒(méi)有哪里是不合適的。

equals方法

通常來(lái)說(shuō)，IDE暴露一起生成equals方法和hashCode方法的選項(xiàng)。這有必要，因?yàn)槲覀兺ǔＰ枰@兩種方法都有一種合適的、一致的實(shí)現(xiàn)（我在此不過(guò)多的具體解釋，假設(shè)我們都知道equals和hashCode契約）。

我不是很反對(duì)IDE為hashCode生成的實(shí)現(xiàn)，它們通常是***的，盡管我們可以進(jìn)一步對(duì)它們加以優(yōu)化。不過(guò)，equals實(shí)現(xiàn)方面存在一個(gè)小問(wèn)題：

public class MyDerivedClass extends MyClass { 
    private final String address; 
 
    public MyDerivedClass(int id, String name, String address) { 
        super(id, name); 
        this.address = address; 
    } 
 
    public String getAddress() { 
        return address; 
    } 
 
    // equals and hashCode 
} 

 這里一切看起來(lái)沒(méi)問(wèn)題，但是出現(xiàn)了嚴(yán)重的情況：這個(gè)類違反了里氏替換原則（Liskov Substitution Principle）。這個(gè)原則是SOLID原則的一部分；簡(jiǎn)而言之，那就是“派生類可充當(dāng)基類，客戶不會(huì)注意到它。”這個(gè)定義有點(diǎn)費(fèi)勁（這個(gè)原則需要用一整篇文章來(lái)介紹），于是我會(huì)用一個(gè)例子來(lái)這個(gè)問(wèn)題，那樣我們可以明白為何我們的equals方法有問(wèn)題。

不妨創(chuàng)建一個(gè)派生類：

public class MyDerivedClass extends MyClass { 
    private final String address; 
    public MyDerivedClass(int id, String name, String address) { 
        super(id, name); 
        this.address = address; 
    } 
    public String getAddress() { 
        return address; 
    } 
    // equals and hashCode 
} 

我忽略了equals和hashCode實(shí)現(xiàn)，因?yàn)樗鼈儗?duì)這個(gè)例子來(lái)說(shuō)沒(méi)有必要。

public static void main(String[] args) { 
    MyClass object1 = new MyClass(1, "name"); 
    MyDerivedClass object2 = new MyDerivedClass(1, "name", "address"); 
    System.out.println(areEquals(object1, object2)); 
} 
public static boolean areEquals(MyClass object1, MyClass object2) { 
    return object1.equals(object2); 
} 

方法areEquals收到MyClass的兩個(gè)實(shí)例。從含有的信息來(lái)看，這兩個(gè)實(shí)例一模一樣，所以我們認(rèn)為areEquals會(huì)返回true。但實(shí)則不然，因?yàn)樽詣?dòng)生成的equals方法執(zhí)行這個(gè)操作：

if (o == null || 
    getClass() != o.getClass()) 
        return false; 

getClass為***個(gè)對(duì)象返回MyClass，為第二個(gè)對(duì)象返回MyDerivedClass，于是我們的方法equals返回false。

我們可以討論這種情況出現(xiàn)的頻率，因?yàn)閮烧叨际遣煌惖膶?shí)例。但是，兩個(gè)字段中所有字段的值一模一樣，果真有意義嗎？實(shí)際上，areEquals的一種替代實(shí)現(xiàn)可能是這樣：

public static boolean areEquals(MyClass object1, MyClass object2) { 
    return object1.getId() == object2.getId() && 
            object1.getName().equals(object2.getName()); 
} 

在這里，結(jié)果是true。

這就是里氏替代原則的大致內(nèi)容。這個(gè)原則的影響之一就是，如果我們覆蓋方法，它就會(huì)添加某個(gè)行為，而不清除基類執(zhí)行的任何操作。顯著違反這個(gè)原則的是，覆蓋一個(gè)方法讓它是空的這種做法（我猜許多人干過(guò)這種事）。

于是，我們需要為方法equals提供一種更好的實(shí)現(xiàn)。它應(yīng)該是這樣子：

@Override 
public boolean equals(Object o) { 
    if (this == o) 
        return true; 
 
    if (!(o instanceof MyClass)) 
        return false; 
 
    MyClass myClass = (MyClass) o; 
 
    if (id != myClass.id) 
        return false; 
 
    if (name != null ? 
            !name.equals(myClass.name) : 
            myClass.name != null) 
                return false; 
 
    return true; 
} 

不是使用getClass，詢問(wèn)對(duì)象知道其類，我們所做的而是，如果它是類的實(shí)例（equals駐留于運(yùn)算符instanceof），要求對(duì)象由參數(shù)傳遞給equals。這個(gè)運(yùn)算符為這個(gè)類及其派生類的實(shí)例返回true。現(xiàn)在，我們的areEquals方法終于按我們所需的方式來(lái)工作。

事實(shí)上，IntelliJ暴露了自動(dòng)生成equals這個(gè)版本的一種方法，但是我們必須認(rèn)真選擇向?qū)С绦虻倪x項(xiàng)，因?yàn)樗谀J(rèn)情況下未勾選，我們必須自行勾選。它是“Accept subclasses as parameters to equals() method”：

使用自動(dòng)代碼生成工具（IDE），要注意這些生成代碼的小瑕疵對(duì)話框本身提到，實(shí)現(xiàn)在默認(rèn)情況下違反了equals契約。Instanceof實(shí)現(xiàn)似乎與一些框架不兼容。這種情況下，我們應(yīng)該改用***個(gè)版本，但是始終要小心由此帶來(lái)的后果。所以，不妨一開始就使用正確的版本，必要時(shí)再改用B計(jì)劃。

原文標(biāo)題：Review your auto-generated code

作者：Raúl Ávila

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】