避免API設計中的基元？

我正在設計一個API。它會有很多方法相同，但有不同的參數基元。避免API設計中的基元？

public void someMethod1(int x); 
public void someMethod1(float x); 
public void someMethod1(double x); 
public void someMethod2(int x, int y); 
... 
public void someMethod3(int x, int y, int z); 
...

由於原語，我要複製粘貼&了很多，我認爲這是隨着時間的推移相當難以維護。在方法和構造函數中避免原語是個好主意嗎？例如，更換上面的將是：

public <T extends Number> void someMethod1(T x); 
public <T extends Number> void someMethod2(T x, T y); 
public <T extends Number> void someMethod3(T x, T y, T z);

編輯：

這有什麼缺點的？

來源

2010-03-07 Pindatjuh

太多問題！您可能想要提出多個問題，您不只是問過API設計中的原語。 – Brabster 2010-03-07 18:29:49

沒有簡單的解決方案，這在Java中：要麼你複製或使用代碼生成器（這是怎麼了，比方說，特羅韋具有快速TIntLongHashMap，其中只使用原語[因此比默認的Java HashMap的快得多]），或者你使用的對象，並承受巨大的表現懲罰。自動（un）裝箱數以百萬計的原語並生成數百萬個不必要的對象是殺死perfs的一種可靠方法。這就是爲什麼對於原始大集合，默認Java API和基於乾淨OO的東西根本不會削減它。那時你使用Trove等東西。這歸結於您的要求。 – SyntaxT3rr0r 2010-03-07 20:37:55

由於Java 1.5及更高版本中的自動裝箱/自動裝箱功能，它將可用。您可以將int傳遞給期望Integer的東西，反之亦然，並且投射將自動發生。這同樣適用於返回值。

請記住，在你的方法的主體中，你會比對它們的某種形式知道得多一點，而不是它們的某種形式Number。如果不關心整數和浮點表示之間的區別，這將僅適用。

這不會增加你的表演 - 演員陣容會有一些小小的懲罰，但你不應該擔心，直到你發現你有一個瓶頸。對於大多數應用程序來說，差異將是微不足道的。

無論使用List而不是陣列，都應該由您的設計決定，但通常建議使用List，除非需要陣列。 List s傾向於更靈活，不需要調整大小，具有API的所有好處，等等。

來源

2010-03-07 18:28:43 danben

APIs是關於語義的，所以我認爲問題的答案如下所述（我應該避免API設計中的原語）取決於你的API的功能。

int addOne(int integer)在語義上是一致的，並且不會出現很多維護問題，因爲它反映了問題域。

Employee getEmployee(int empID)可能被歸類爲不適當，並且如果您的員工ID改變（例如對於字符串），則會出現維護問題。

來源

2010-03-07 18:32:37 Brabster

要回答您關於List<T>與T[]的問題，請提供有關實施的詳細信息。

List<T>比T[]更易維護，因爲您可以在不更改客戶端代碼的情況下更改List實現。

如果不應該由客戶端代碼修改列表，Iterable<T>會更好，因爲您沒有提供任何有關實現細節的信息，也不會阻止迭代以外的操作。

來源

2010-03-07 18:35:06 Brabster

Iterable是一個很好的！謝謝！ – Pindatjuh 2010-03-07 18:40:23

P.S.我編輯的問題是：這是閹'名單這個問題的回答'是一個很好的替代'T []'。 – Pindatjuh 2010-03-07 19:03:24

這是一個有效的模式，有時用於在模型 - 視圖 - 控制器系統中定義屬性。此外，如果您使用-128至127範圍內的整數，則它們將由Java自動緩存，如果使用Integer.valueOf(int)進行轉換，則可以在創建Integer時加快速度。您還可以使用始終至少爲127的屬性java.lang.Integer.IntegerCache.high來增加緩存的範圍。自動裝箱也可能會使用整數緩存，但我不確定。如果您的課程是爲在高性能環境中使用而設計的，那麼我會考慮其他替代方案並使用原語。

來源

2010-03-07 18:55:58

避免API設計中的基元？

回答

相關問題