Java的Comparable接口的一個陷阱
Java的Comparable接口提供一個對實現(xiàn)了這個接口的對象列表進行排序的辦法。原始的排序?qū)τ诤唵蔚膶ο髞碚f具有意義，但是當(dāng)我們面對復(fù)雜的面向?qū)ο蟮臉I(yè)務(wù)邏輯對象時，事情變得復(fù)雜的多。從業(yè)務(wù)經(jīng)理的角度來看，一些交易對象的自然順序可能是按照交易的價值來排序的，但是從系統(tǒng)管理員的角度來看，這個排序的規(guī)則可能是交易的速度。所以在大多數(shù)情況下，并沒有明確的業(yè)務(wù)領(lǐng)域?qū)ο蟮淖匀慌判蛞?guī)則。
創(chuàng)新互聯(lián)是一家專業(yè)提供赤壁企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站制作、網(wǎng)站建設(shè)、成都h5網(wǎng)站建設(shè)、小程序制作等業(yè)務(wù)。10年已為赤壁眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進行中。
假設(shè)我們找到了一個需要排序的類，比如說Campany。我們把公司的offical name作為主關(guān)鍵字，把id作為次要關(guān)鍵字。這個類的實現(xiàn)如下：
- public class Company implements Comparable
{ - private final String id;
- private final String officialName;
- public Company(final String id, final String officialName) {
- this.id = id;
- this.officialName = officialName;
- }
- public String getId() {
- return id;
- }
- public String getOfficialName() {
- return officialName;
- }
- @Override
- public int hashCode() {
- HashCodeBuilder builder = new HashCodeBuilder(17, 29);
- builder.append(this.getId());
- builder.append(this.getOfficialName());
- return builder.toHashCode();
- }
- @Override
- public boolean equals(final Object obj) {
- if (obj == this) {
- return true;
- }
- if (!(obj instanceof Company)) {
- return false;
- }
- Company other = (Company) obj;
- EqualsBuilder builder = new EqualsBuilder();
- builder.append(this.getId(), other.getId());
- builder.append(this.getOfficialName(), other.getOfficialName());
- return builder.isEquals();
- }
- @Override
- public int compareTo(final Company obj) {
- CompareToBuilder builder = new CompareToBuilder();
- builder.append(this.getOfficialName(), obj.getOfficialName());
- builder.append(this.getId(), obj.getId());
- return builder.toComparison();
- }
- }
這個實現(xiàn)看起來沒問題，假設(shè)現(xiàn)在這個類提供的信息不夠使用，我們又創(chuàng)建了這個類的一個子類CompanyDetail類用以擴展他。例如我們想以一個表的形式顯示公司的信息，我們就可以用這個類。
- public class CompanyDetails extends Company {
- private final String marketingName;
- private final Double marketValue;
- public CompanyDetails(final String id, final String officialName, final String marketingName, final Double marketValue) {
- super(id, officialName);
- this.marketingName = marketingName;
- this.marketValue = marketValue;
- }
- public String getMarketingName() {
- return marketingName;
- }
- public Double getMarketValue() {
- return marketValue;
- }
- @Override
- public int hashCode() {
- HashCodeBuilder builder = new HashCodeBuilder(19, 31);
- builder.appendSuper(super.hashCode());
- builder.append(this.getMarketingName());
- return builder.toHashCode();
- }
- @Override
- public boolean equals(final Object obj) {
- if (obj == this) {
- return true;
- }
- if (!(obj instanceof CompanyDetails)) {
- return false;
- }
- CompanyDetails other = (CompanyDetails) obj;
- EqualsBuilder builder = new EqualsBuilder();
- builder.appendSuper(super.equals(obj));
- builder.append(this.getMarketingName(), other.getMarketingName());
- builder.append(this.getMarketValue(), other.getMarketValue());
- return builder.isEquals();
- }
- }
這個類的實現(xiàn)看起來還是沒什么問題，但是事實上是有問題的，我們可以寫一個test指出問題在哪里。當(dāng)我們沒有對父類的所有細(xì)節(jié)加以注意時，問題就來了。
- CompanyDetails c1 = new CompanyDetails("231412", "McDonalds Ltd", "McDonalds food factory", 120000.00);
- CompanyDetails c2 = new CompanyDetails("231412", "McDonalds Ltd", "McDonalds restaurants", 60000.00);
- Set
set1 = CompaniesFactory.createCompanies1(); - set1.add(c1);
- set1.add(c2);
- Set
set2 = CompaniesFactory.createCompanies2(); - set2.add(c1);
- set2.add(c2);
- Assert.assertEquals(set1.size(), set2.size());
我們構(gòu)造了兩個set，但是結(jié)果是assert的結(jié)果是不相等。這是為什么？其中一個set是一個HashSet，他依賴對象的hashCode()和equals()方法，但是另一個是TreeSet，他只是依賴Comparable接口，而這個接口在子類中我們并沒有實現(xiàn)。在領(lǐng)域?qū)ο蟊粩U展的時候這是很常見的一個錯誤，但是更重要的是這是不好的編碼約定造成的。我們使用Apache Commons包中的builder來實現(xiàn)hashCode(),equals().和compareTo()方法。這些builder提供了appendSuper()方法，此方法指示了如何調(diào)用這些方法在父類中的實現(xiàn)。如果你看過Joshua Bloch 的Effective Java，你會發(fā)現(xiàn)這是錯誤的。如果我們在子類中添加成員變量，在不違反對稱規(guī)則的情況下，我們就不能正確的實現(xiàn)equals()方法和compareTo()方法。我們應(yīng)該使用組合的方式而不是繼承。如果我們使用組合的方式構(gòu)造CompanyDetails，對于Comparable接口來說沒有任何問題，因為我們沒有自動的實現(xiàn)，而且在默認(rèn)的情況允許不同的行為。而且我們也能滿足正確的equals()和hashCode()的需求。
這篇文章提到的問題非常普遍，但是經(jīng)常被忽視。Comparable接口的問題實際是由于不好的約定和對使用的接口需求的錯誤理解造成的。作為一個Java開發(fā)人員或架構(gòu)師，你應(yīng)該特別注意這樣的事情，并遵守良好的編碼習(xí)慣和做法。 越大的項目，這種問題就越顯得重要。這里我總結(jié)了一個使用Comparable接口的最佳實踐，可以避免這個錯誤。
Java的Comparable接口的設(shè)計和使用的最佳實踐：
- 了解你需要創(chuàng)建的領(lǐng)域?qū)ο?，如果對象沒有明確的排序規(guī)則，請不要實現(xiàn)Comparable接口。
- 更多的使用Comparator而不是Comparable，Comparator在更多的業(yè)務(wù)使用方式時要顯得更為實用。
- 如果你需要創(chuàng)建依賴Comparable接口的接口或者庫，如果可能的話你提供自己的Comparator實現(xiàn)，否則就寫一個良好的文檔指明在你的接口實現(xiàn)類中如何實現(xiàn)。
- 遵守良好的編碼習(xí)慣和做法。Effective Java是很好的推薦。
分享文章：Java的Comparable接口的一個陷阱
本文網(wǎng)址：http://m.jiaotiyi.com/article/dphpscp.html