dependency-injection - 实用单例和依赖注入(inject)问题

Question

假设我有一个名为 PermissionManager 的类，它在我的系统中应该只存在一次，并且基本上实现了为我的应用程序中的各种操作管理各种权限的功能。现在我的应用程序中有一些类需要能够在其方法之一中检查某个权限。此类的构造函数当前是公共(public)的，即由 API 用户使用。

直到几周前，我才会让我的类(class)在某处调用以下伪代码:

     PermissionManager.getInstance().isReadPermissionEnabled(this)

但是由于我注意到这里的每个人都讨厌单例+这种耦合，所以我想知道更好的解决方案是什么，因为我读到的反对单例的论点似乎是有道理的(不可测试，高耦合等)。

那么我真的应该要求 API 用户在类的构造函数中传入一个 PermissionManager 实例吗？即使我只希望我的应用程序存在一个 PermissionManager 实例？

还是我要解决这一切都错了，应该有一个非公共(public)构造函数和一个工厂在某个地方为我传递 PermissionManager 的实例？

附加信息 请注意，当我说“依赖注入(inject)”时，我指的是 DI Pattern ...我没有使用任何 DI 框架，如 Guice 或 Spring。 (...然而)

Answer 1

如果您使用的是依赖注入(inject)框架，那么处理此问题的常用方法是在构造函数中传入 PermissionsManager 对象，或者拥有框架为您设置的 PermissionsManager 类型的属性。

如果这不可行，那么让用户通过工厂获取此类的实例是一个不错的选择。在这种情况下，工厂在创建类时将 PermissionManager 传递给构造函数。在您的应用程序启动时，您将首先创建单个 PermissionManager，然后创建您的工厂，传入 PermissionManager。

您是正确的，类的客户通常很难知道在哪里找到正确的 PermissionManager 实例并将其传递(甚至关心您的类使用 PermissionManager 的事实)。

我见过的一种折衷解决方案是给你的类一个 PermissionManager 类型的属性。如果已设置属性(例如，在单元测试中)，则使用该实例，否则使用单例。就像是:

PermissionManager mManager = null;
public PermissionManager Permissions
{
  if (mManager == null)
  {
    return mManager;
  }
  return PermissionManager.getInstance();
}

当然，严格来说，你的 PermissionManager 应该实现某种 IPermissionManager 接口(interface)， 那是您的其他类应该引用什么，以便在测试期间可以更轻松地替换虚拟实现。