1

我想在我的 android 应用程序中有一个辅助类，例如 Convert 或 Utils。我遇到的典型问题是：

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() 是什么。所以这给我留下了两个选择：

  1. 每次我想使用辅助方法时都传递一个上下文，这是垃圾

  2. 子类应用程序，修改我的清单，然后创建一个引用，如下所示：

    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()在我需要的任何地方做。

问题：这不可能是正确的，优雅的方式是什么？

4

2 回答 2

5

如果你对应用程序进行子类化，这显然会起作用，但你最终可能会得到一个巨大的、可怕的类，它会做一大堆不相关的事情——粗暴地践踏单一职责原则。

是的，将上下文传递给实用程序类有点麻烦和烦人，但这意味着您可以为每种类型的实用程序（例如 StringUtils 或其他）创建类，并且至少将职责分开。

我建议不要在任何地方使用 App.getContext，因为这意味着您的所有实用程序类都将依赖于 App，这使得重用它们变得困难。如果传入上下文，则可以更轻松地在其他应用程序中重用某些实用程序类。

所以我会说使用单独的类，并将该上下文传递给方法。它有点难看，但在我看来，比替代品要丑得多。

于 2012-04-13T15:22:06.663 回答
0

每次我想使用辅助方法时都传递一个上下文，这是垃圾

对我来说，这听起来像是 OOP 宗教。我实际上会传入DisplayMetrics, 因为这是函数真正需要计算其答案的内容。

于 2014-03-10T19:34:32.947 回答