2016-02-12 56 views
0

我寫了一個API,其中一個方法以java.util.Map作爲參數。所提供的地圖包含必須按廣告訂單排序的數據。所以我特別提到了這個說法,作爲java.util.LinkedHashMap。但是我的一位同事要求我只是將參數聲明爲Map,並且API的javadoc應該讓客戶端知道。LinkedHashMap或Map

我不明白爲什麼java.util.LinkedHashMap是一個不好的做法,爲什麼我應該通過接口。這不是不必要的工作,如果客戶不注意文檔,可能會導致功能錯誤(我知道他們應該這樣做)。

+4

如果它必須作爲'LinkedHashMap'函數,則需要一個'LinkedHashMap'。如果它只能作爲一個Map來使用,則需要一個Map。 – Vulcan

+0

你的意思是,如果它只起到LinkedHashMap的作用,那麼應該使用LinkedHashMap? – user2296988

+1

誰將使用API​​?正如我所看到的,在類型安全性和多態性之間存在權衡。一方面,通過要求'LinkedHashMap',你保證地圖將具有所需的排序屬性。但另一方面,有人可能有另一個'Map'實現,它也滿足所需的排序屬性,但如果您需要'LinkedHashMap',則它將不可用。 – Ben

回答

1

你的API對參數兩個要求:

  1. 這是一個Map
  2. 它在迭代插入順序。

LinkedHashMap滿足這些要求,但沒有文件或規範的任何地方,說所有的插入順序圖必須從LinkedHashMap繼承。通過指定LinkedHashMap,您可以保證參數符合您的要求,但是您也可能會禁止某個擁有Map的人按您要求的順序迭代您的API,但碰巧使用其他實現。

如果有人來一些自定義ArrayBackedHashMap怎麼辦?他們有一個滿足您的實際需求的對象(Map和迭代訂單),但是您的聲明爲LinkedHashMap可以阻止其工作。一般來說,如果你希望別人使用你的代碼(以及大部分其他時間),那麼你應該嘗試接受任何滿足你實際需求的東西。在這種情況下,您的第二個要求不與任何聲明類型正式綁定的事實意味着您不應該嘗試使用某種類型來強制執行它。相反,請在JavaDoc中聲明需求。

+0

作爲附加示例,請考慮一個java.util.TreeMap,其中Comparator基於插入時間。它在比較器順序中迭代,這也是插入順序。 –

0

您的同事可能意味着您需要記錄Map必須按插入順序排列,除LinkedHashMap之外的其他類別可滿足該要求。

LinkedHashMap作爲一個合同在任何情況下似乎都很弱,因爲它不能保證重新插入後的順序。

+0

在這種情況下不會有任何重新插入。此功能爲pdf中的每個頁面設置書籤。 – user2296988

1

根據喬希布洛赫,你應該總是使用接口作爲參數,而不是它的實現,除非你使用該實現的具體方法。

試想,如果你的客戶都有自己的執行Map其中collection保持插入的順序和有你的客戶(效率,業務邏輯等)的一些好處。另一個例子可能是谷歌/ Eclipse/Oracle訂購的Map的一些新的更有效的實現,我不知道。

因此,除非您使用LinkedHashMap的特定方法,否則應避免將其指定爲您的參數。也許嘗試在插入之前對您的Map進行排序,或者專注於提供良好的javadoc。

+0

Thanks.makes sense – user2296988