Praktische Singleton & Dependency Injection Frage

Question

Sagen, ich habe eine Klasse namens permission, die nur einmal für mein System existieren sollten und erfüllt im Wesentlichen die Funktion der verschiedenen Berechtigungen für verschiedene Aktionen in meiner Anwendung zu verwalten. Jetzt habe ich eine Klasse in meiner Anwendung, die eine gewisse Berechtigung in einem seine Methoden muss in der Lage zu überprüfen. Dieser Konstruktor der Klasse wird derzeit öffentlich, das heißt von API-Benutzer verwendet wird.

Bis vor ein paar Wochen her, hätte ich hatte einfach meine Klasse rufen Sie den folgenden Pseudo-Code irgendwo:

     PermissionManager.getInstance().isReadPermissionEnabled(this)

Aber da ich hier alle hassen Singletons bemerkt haben + diese Art der Kupplung, ich frage mich, was die bessere Lösung wäre, da die Argumente, die ich gegen Singletons gelesen haben scheinen Sinn (nicht prüfbar, hohe Kopplung, etc.) zu machen .

Also sollte ich tatsächlich benötigen API Benutzer in einer permission Instanz passieren in den Konstruktor der Klasse? Auch wenn ich für meine Anwendung existieren nur eine einzige Instanz permission will?

Oder soll ich das über alle falsch und sollte einen nicht-öffentlichen Konstruktor und eine Fabrik irgendwo haben, die für mich in der Instanz von permission passiert?

---

Weitere Informationen: Beachten Sie, dass, wenn ich "Dependency Injection" sagen, ich rede über die DI Muster ... ich bin kein DI Framework wie Guice oder Frühling verwenden. (... noch)

Answer 1

Wenn Sie einen Abhängigkeit-Injection-Framework verwenden, dann der gemeinsame Weg zu handhaben ist, entweder in einem PermissionsManager Objekt übergibt im Konstruktor oder eine Eigenschaft vom Typ PermissionsManager zu haben, dass die Rahmen-Sets für Sie.

Wenn dies nicht möglich ist, dann haben Benutzer eine Instanz dieser Klasse über Fabrik erhalten, ist eine gute Wahl. In diesem Fall geht die Fabrik die permission in das Konstruktor, wenn sie die Klasse erstellt. In Ihrer Anwendung Start-up würden Sie die einzelne permission zuerst erstellen, dann Fabrik erstellen, in den permission vorbei.

Sie sind richtig, dass es für die Kunden einer Klasse normalerweise unhandlich ist zu wissen, wo die richtige permission Instanz zu finden und gibt es in (oder sogar über die Tatsache zu kümmern, dass Ihre Klasse eine permission verwendet).

Eine Kompromisslösung ich gesehen habe, ist Ihrer Klasse eine Eigenschaft vom Typ permission zu geben. Wenn die Eigenschaft gesetzt worden ist (beispielsweise in einem Unit-Test), verwenden Sie diese Instanz, sonst hat man die Singleton verwenden. So etwas wie:

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

Natürlich, streng genommen, Ihre permission sollte eine Art von IPermissionManager-Schnittstelle implementieren und das ist , was Ihre andere Klasse sollte verweisen, so eine Dummy-Implementierung leichter während des Tests ersetzt werden kann.

Answer 2

Sie können in der Tat zunächst die permission injiziert wird. Dies wird Ihre Klasse mehr prüfbar machen.

Wenn diese Probleme für die Benutzer dieser Klasse macht, können Sie haben sie eine Factory-Methode verwenden oder eine abstrakte Fabrik. Oder Sie können einen parameterlosen Konstruktor hinzufügen, die für sie, dass die permission injiziert zu nennen, während die Tests einen anderen Konstruktor verwenden, die Sie verwenden können, die permission zu verspotten.

Entkoppelung Ihre Klassen mehr macht Ihre Klassen flexibler, aber es kann auch sie schwerer zu bedienen. Es hängt von der Situation, was Sie benötigen. Wenn Sie nur eine permission haben und haben kein Problem, die Klassen zu testen, die es verwenden, dann gibt es keinen Grund, DI zu verwenden. Wenn man die Leute wollen in der Lage sein, ihre eigenen permission Implementierung hinzuzufügen dann DI ist der Weg zu gehen.

Answer 3

Wenn Sie die Dependency Injection Weise abonniert, Dinge zu tun, was auch immer Klassen Ihre PermissionManager brauchen sollte es als eine Objektinstanz injiziert. Der Mechanismus, der seine Instantiierung steuert (die Singletons Natur zu erzwingen) arbeitet auf einer höheren Ebene. Wenn Sie ein Dependency Injection-Framework wie Guice verwenden, können sie die Durchsetzung Arbeit tun. Wenn Sie Ihr Objekt Verdrahtung von Hand tun, Dependency Injection favorisiert Code Gruppierung, die Instanziierung (neue Betreiber der Arbeit) tut weg von Ihrer Business-Logik.

So oder so, obwohl die klassischen "Hauptstadt-S" Singleton allgemein als Anti-Muster im Zusammenhang mit der Dependency Injection zu sehen ist.

Diese Beiträge haben für mich in der Vergangenheit einsichtig gewesen:

• Mit Dependency Injection Singletons zu vermeiden
• Wie über das denken "new" Operator mit Bezug auf Unit Testing

Answer 4

  

Also sollte ich tatsächlich benötigen API Benutzer in einer permission Instanz passieren in den Konstruktor der Klasse? Auch wenn ich für meine Anwendung existieren nur eine einzige Instanz permission will?

Ja, das ist alles, was Sie tun müssen. Ob eine Abhängigkeit ist ein Singleton / pro Anfrage / pro Faden oder eine Factory-Methode liegt in der Verantwortung des Containers und Konfiguration. In der .NET-Welt würden wir in idealer Weise die Abhängigkeit von einer IPermissionsManager Schnittstelle Kopplung weiter zu reduzieren haben, gehe ich davon aus der besten Praxis in Java ist auch.

Answer 5

Das Singletonmuster ist für sich nicht schlecht, was macht es hässlich die Art und Weise ist es häufig verwendet wird, als das Erfordernis der nur eine einzige Instanz einer bestimmten Klasse zu wollen, was ich denke, es ist ein großer Fehler.

In diesem Fall würde ich permission eine statische Klasse machen, es sei denn aus irgendeinem Grund Sie es brauchen ein instanciable Typ zu sein.