是繼承應用程序的唯一方法在Android中實現靜態輔助方法？

我想在我的android應用程序中有一個輔助類，如Convert或Utils。我有的典型問題是：是繼承應用程序的唯一方法在Android中實現靜態輔助方法？

public class Convert { 

    private Convert() { 
     // I can't be instantiated 
    } 

    public static int pxToDp(float pixels) { 
     DisplayMetrics displayMetrics = getResources().getDisplayMetrics(); 
     return (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, pixels, displayMetrics); 
    } 
}

上面的失敗當然是因爲Convert不知道getResources（）是什麼。所以這讓我兩個選擇：

傳遞一個方面，我想用一個輔助方法，它是垃圾

子類應用程序，修改我的表現各一次，然後創建一個參考，這樣的：

public class App extends Application { 

    private static Context mContext; 

    @Override 
    public void onCreate() { 
     super.onCreate(); 
     mContext = this; 
    } 

    public static Context getContext() { 
     return mContext; 
    } 
}

然後做App.getContext()無處不在我需要它。

問題：這不可能是正確的，什麼是優雅的方式繼續？

來源

2012-04-13 Stephan Tual

我希望我能不止一次地+1這個我個人用「傳遞上下文作爲參數」並且對此感到可怕...... – mfrankli 2012-04-13 15:15:48

子類化應用程序有什麼問題？ – 2012-04-13 15:16:03

如果你明確地使用應用程序，但最終可能會遇到一個巨大的，可怕的類，它會完成大量不相關的事情 - 在單一職責原則上橫行霸道。

是的，它將一個Context傳遞到一個工具類中有點麻煩和煩人，但它意味着你可以爲每種類型的工具創建類（例如StringUtils或其他），並且至少將職責分開。

我建議不要在任何地方使用App.getContext，因爲它意味着所有的實用程序類將依賴於應用程序，這使得它很難重用它們。如果您通過上下文傳遞，則可以更輕鬆地在其他應用程序中重用某些實用程序類。

所以我會說使用單獨的類，並將該上下文傳遞給方法。這有點難看，但在我看來，這比替代品要難得多。

來源

2012-04-13 15:22:06

這是正確的。如果你已經在Android中編程了很多，你會注意到API正是如此。唯一值得關注的是調用實用類方法時額外的開銷。如果您的工具類不需要是靜態的，您可以簡單地創建一個包含在實例化時傳遞的上下文的成員字段。這也可以工作，並防止每次都需要傳遞一個。這裏需要注意的是，如果實用類方法依賴於實例化的類，則不能再聲明爲靜態類。 – dcow 2012-04-13 15:33:53

而且我相信你不想要一堆實用課程讓你珍貴的記憶變得瑣碎。所以，你可以讓它成爲一個單身人士。但是，這樣做意味着它一次只能在一個環境中工作。這可能很好，但理想情況下，實用程序類是從任何上下文中調用的。 – dcow 2012-04-13 15:36:19

我想使用一個輔助方法，它是垃圾

這聽起來像OOP宗教對我來說每次通過一個背景。我實際上會通過DisplayMetrics，因爲這是函數真正需要計算其答案的。

來源

2014-03-10 19:34:32 japreiss

是繼承應用程序的唯一方法在Android中實現靜態輔助方法？

回答

相關問題