Der testfreundliche Singleton – Versuch 2.0

Gestern habe ich bereits ein Post zum testbaren Singleton geschrieben, in welchem ich es mir zur Aufgabe gemacht hatte eine Möglichkeit zu finden Singletons so umzusetzen, dass sie möglichst einfach zu testen und ersetzen sind. Dies ist mir nur teilweise gelungen.

Das erste System das ich vorstellte, erlaubte zwar ein Testen des Singletons, nicht aber den Austausch durch ein Fake-Objekt. Die zweite Fassung ermöglichte zwar das Ersetzen und Testen, war in meinen Augen aber zu aufwändig. Dazu kommt, dass beide Systeme dem Entwickler die Freiheit gewähren die tatsächliche Singleton-Funktionalität zu nutzen oder sich einfach selbst eine Instanz der Klasse zu erstellen.

Die Herausforderung

Bevor ich mit meiner Erläuterung weiter mache, hier noch einmal die Aufgabenstellung:

  • Es darf von der Klasse nur eine Instanz geben
  • Diese Instanz muss global verfügbar sein
  • Diese Instanz muss selbst testbar sein
  • Man muss diese Instanz ersetzen können um Testbestandteile besser zu isolieren
  • Die Lösung muss möglichst einfach sein und darf nicht Gebrauch von gängigen Frameworks machen

Wie sich daraus schon ablesen lässt, war meine Überschrift das letzte Mal falsch. Denn es geht nicht nur darum einen testbaren Singleton zu erstellen, sondern einen Singleton der nach Möglichkeit so wenig böse Eigenschaften hat wie möglich.

Eine Sache des Prinzips

Bei meinem letzten Versuch habe ich hauptsächlich auf Separation of Concerns gebaut und war der festen Überzeugung, eine Klasse dürfe nicht wissen wie ihre Instanzierung von Statten geht. Dies hat den Vorteil, dass ihre Wiederverwendbarkeit steigt, da sie ohne Weiteres auch ohne die Eigenschaft einzigartig zu sein überleben kann.

Der Nachteil ist jedoch, dass ich das Problem verkompliziere. Wie häufig ändert denn ein Singleton seine zentrale Eigenschaft? Wie häufig wird aus ihm eine normale Klasse? Ich würde einmal sagen: sehr selten.

Im Sinne von KISS opfere ich nun also die Möglichkeit den Singleton nachträglich leicht wieder zu verwenden, vereinfache aber seinen gesamten Aufbau und seine Handhabe. Dazu nutze ich Dinge die ich im letzten Posting bereits angesprochen hatte.

An die Umsetzung

Ich habe bei der Umsetzung wieder bewusst auf Threadsicherheit verzichtet um das Beispiel nicht zu verkomplizieren.

Der folgende Singleton sieht dem üblichen sehr ähnlich. Er hat aber zwei entscheidende Unterschiede. Sowohl Konstruktor als auch das Feld, welches die Instanz hält, sind protected und nicht private!

Der protected Konstruktor verbietet demnach die Instanzierung des eigentlichen Singleton, nicht aber die Vererbung. Es ist somit möglich eine Kindklasse zu erstellen.

public class TestFriendlySingleton : ITestFriendlySingleton
{
   /// <summary>
   /// protected instance allows mocking
   /// </summary>
   protected static ITestFriendlySingleton _instance;

   public static ITestFriendlySingleton Instance
   {
      get {
          return _instance ?? (_instance = new TestFriendlySingleton());
      }
   }

   /// <summary>
   /// Protected Constructor allows to instantiate child classes
   /// </summary>
   protected TestFriendlySingleton()
   {}
}

Dieses Kind wiederum hat die Möglichkeit die Instanz des Singletons zu überschreiben. Da ich in meinem Fall zudem die Instanz mit einem Interfacetypen deklariere ermögliche ich es sie mit jedem beliebigen ITestFriendlySingleton zu ersetzen.

public class TestFriendlySingletonStub : TestFriendlySingleton
{
   public static void SetInstance(ITestFriendlySingleton fake)
   {
      _instance = fake;
   }
}

Das Ersetzen wird ermöglicht, da ich direkt den Wert des Felds setzen kann. Ist das Feld ungleich null wird dann durch den ?? Operator in der Instance-Property des Singletons auch keine Instanz erzeugt.

Somit missbrauche ich im Tesfall die Property des Singletons um die Referenz des Fake-Objekts zurück zu geben. Nach außen hin hat sich somit nichts geändert, intern wurde jedoch die Funktionalität des Singletons durch eine andere ersetzt.

Ein (ausführliches) Beispiel

Wie könnte nun aber der Einsatz dieses Konstrukts konkret aussehen? Hierzu bemühe ich mal wieder den allseits beliebten Logger. Wobei dieser der Einfachheit halber nur eine Textnachricht ohne Drumherum loggt. Vorgeschrieben wird diese Funktion über ein Interface.

public interface ILogger
{
    void Log(string message);
}

Der tatsächliche Logger mag dann in etwa so aussehen:

public class Logger : ILogger
{
    protected static ILogger _instance;

    /// <summary>
    /// Gett of the one and only instance
    /// </summary>
    public static ILogger Instance
    {
        get
        {
            return _instance ?? (_instance = new Logger());
        }
    }

    /// <summary>
    /// Protected Constructor allows to instantiate child classes
    /// </summary>
    protected Logger()
    { }

    /// <summary>
    /// Logs the specified message.
    /// </summary>
    public void Log(string message)
    {
        // do something
    }
}

Der Stub hat sich nicht wirklich verändert.

public class LoggerStub : Logger
{
    public static void SetInstance(ILogger mock)
    {
        _instance = mock;
    }
}

Nun aber zum eigentlichen Fakeobjekt. Dieses macht nichts mit der übergebenen Nachricht. Warum? Weil ein tatsächlicher Logger auf das Dateisystem zugreifen möchte und wir genau das nicht wollen. Wir isolieren also unseren Testgegenstand (Subject under Test – SUT) um die Fehleranfälligkeit zu verringern. Alternativ zu diesem Dummy, kann man natürlich auch jedes beliebige Isolation Framework nutzen.

public class LoggerDummy : ILogger
{
    public void Log(string message)
    {}
}

Das Setup für ein Test könnte dann wie folgt aussehen und ist wirklich sehr einfach geraten.

LoggerStub.SetInstance(new LoggerDummy());

Abnahmetest

Überprüfen wir mal ob die zuvor gestellten Anforderungen erfüllt sind:

Es darf von einer Klasse nur eine Instanz geben
  • Tut es; dank protected Konstruktor können nur die Kindklassen frei instanziert werden
Die Instanz muss global verfügbar sein
  • Ist sie; immerhin ist das Feld und die Property static
Die Instanz muss selbst testbar sein
  • Dadurch, dass man die Instanzvariable immer wieder neu setzen kann, können ältere Zustände des Singleton überschrieben werden. Demnach können sich Tests nicht untereinander beeinflussen
Man muss die Instanz ersetzen können um Testbestandteile besser zu isolieren
  • Dank Interface, kann man das Instanz-Feld mit jeder beliebigen Klasse überbügeln
Die Lösung muss möglichst einfach sein und darf nicht Gebrauch von Frameworks machen
  • Frameworks habe ich nicht verwendet. Über Einfachheit lässt sich streiten, aber diese Art eines Singletons ist recht nah an der üblichen Implementierung und fühlt sich deshalb nicht falsch an.

Test bestanden!

Fazit

Mit der hier beschrieben Lösung bin ich eigentlich recht glücklich. Dennoch würde ich gerne die Instanzverwaltung auslagern. Vielleicht in eine Basisklasse welche von allen Singletons abgeleitet wird. Leider funktioniert das mit dem protected Konsturktor dann nicht mehr und demnach können hier verschiedene Instanzen erstellt werden.

Eines zeigt mir aber der Vorgang noch: Clean Code Praktiken sind wichtig. Sie zeigen uns einen guten Weg auf mit Problemen umzugehen bzw. diese zu vermeiden. Sie können uns aber im Alltagsgeschäft nur eine Hilfe sein und keine Lösung. Wie auch, dafür sind die Aufgabenstellungen viel zu komplex und unterschiedlich. Es verhält sich also wie mit den Desingpatterns, man muss immer abwägen ob der Einsatz sinnvoll ist und welchem man Vorrang gibt.

3 Kommentare

  1. Mir ist nicht ganz klar, wie man eine abgeleitete Klasse mit der hier vorgestellten Instance-Methode erzeugt. Man könnte eine eigene Methode MyInstance erstellen, aber das verstößt mindestens gegen das Liskov-Prinzip. Oder an überschreibt das _instance Member, dann hat man aber 1 Instanz unnötig erstellt. Letztendlich gelangt man wahrscheinlich zu einer Factory-Klasse, die wieder ganz eigene Probleme mit sich bringt.

    Mein Ansatz wäre adhoc, auf die Angabe des Lebenszyklus der Klasse zu verzichten, so daß sie auf jeden Fall testbar ist, und dann später bei der DI-Integration anzugeben, daß der Lifetime Cycle bitte ein Singleton darstellen soll.

    1. Ich habe dem Artikel jetzt noch ein Beispiel hinzugefügt, wodurch alles etwas anschaulicher sein sollte.

      Es ist definitiv nicht so, dass man eine Instanz des eigentlichen Singleton umsonst erstellt. Diese wird ja nur erstellt wenn man auf die Instance-Property zugreift bevor _instance gesetzt wurde. Setzt man das Feld vor dem Aufruf der Property wird auch keine Instanz erzeugt.

      Das Liskov-Prinzip ist in soweit verletzt, dass Kindklassen einen öffentlichen Konstruktor haben können und demnach auch normal über new instanzierbar sind.

      Du hast natürlich recht, dass es über Dependency Injection leichter geht. Aber genau das wollte ich nicht einsetzen. Der Grund dafür ist, dass es viele Projekte gibt die aus irgend einem Grund kein IoC-Framework nutzen. Genau diesen wollte ich jetzt aber eine Möglichkeit geben die Klippen des Singletons zu umschiffen.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

zwei − zwei =

Bitte folgende Aufgabe lösen um fortzufahren

Wieviel ist 12 + 8 ?
Please leave these two fields as-is: