设计 – 实践单身和依赖注入问题

说我有一个叫PermissionManager的类,对于我的系统应该只存在一次,并且基本上完成了在我的应用程序中管理各种操作的各种权限的功能.现在我在我的应用程序中有一些类,需要在其中一个方法中检查某个权限.此类的构造函数目前是公开的,即由API用户使用.

直到几个星期前,我会简单地让我的类调用以下伪代码：

PermissionManager.getInstance().isReadPermissionEnabled(this)

但是,由于我已经注意到这里的每个人都讨厌这种耦合,所以我想知道更好的解决方案是什么,因为我反对单身人士的观点似乎是有道理的(不可测试,高耦合等).

那么我实际上是否需要API用户在类的构造函数中传入PermissionManager实例？即使我只想为我的应用程序存在一个PermissionManager实例？

或者我会这样做是错误的,应该有一个非公共的构造函数和一个工厂在某个地方传递给我的PermissionManager的实例？

附加信息请注意,当我说“依赖注入”时,我在谈论DI Pattern …我没有使用像Guice或Spring这样的任何DI框架. (…然而)

如果您使用依赖注入框架,那么处理此方法的常见方法是传递构造函数中的PermissionsManager对象,或者具有框架为您设置的类型PermissionsManager的属性.

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

你是正确的,对于一个类的客户端来说,通常是笨重的,知道在哪里找到正确的PermissionManager实例并将其传递(甚至关心你的类使用PermissionManager的事实).

我看到的一个妥协的解决方案是给你的类一个属性类型PermissionManager.如果属性已设置(例如,在单元测试中),则使用该实例,否则使用单例.就像是：

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

当然严格来说,您的PermissionManager应该实现某种类型的IPermissionManager接口,这就是您的其他类应该引用的,所以在测试过程中可以更容易地替代虚拟实现.

原文地址：https://www.jb51.cc/javaschema/281910.html