Funktionen und Variablen

Eine Verallgemeinerung des SRP stellt Curly’s Law dar, welches SRP, methods should do one thing, once and only once (OAOO), don’t repeat yourself (DRY) und single source of truth (SSOT) zusammenfasst. Das SRP kann und soll demnach für alle Aspekte eines Softwareentwurfs angewendet werden. Dazu gehören nicht nur Klassen, sondern unter anderem auch Funktionen und Variablen. Es ist daher auch bei der Verwendung von nicht-objektorientierten Programmiersprachen und dem Entwurf von Serviceschnittstellen gültig.

Beispiel
In dem folgenden Beispiel wird eine Reihe von Zahlen sortiert:

var numbers = new [] { 5,8,4,3,1 };
numbers = numbers.OrderBy(i => i);

Da die Variable numbers zuerst die unsortierten Zahlen repräsentiert und nachher die sortierten Zahlen, wird Curly’s Law verletzt. Dies lässt sich auflösen, indem eine zusätzliche Variable eingeführt wird:

var numbers = new [] { 5,8,4,3,1 };
var orderedNumbers = numbers.OrderBy(i => i);

Anwendungen

Auch in der Unix-Philosophie kommt ein ähnliches Prinzip vor, denn hier sollen Anwendungen einen einzelnen Zweck erfüllen.

Anwendungen und Benutzerschnittstellen nach einem einzelnen Zweck aufzuteilen, besitzt nicht nur in der Entwicklung Vorteile. Auch für Benutzer sind Programme und Benutzerschnittstellen mit einem klar bestimmten Aufgabenzweck besser verständlich und schneller erlernbar. Nicht zuletzt ergeben sich Vorteile bei beschränkten Bildschirmgrößen, wie dies z. B. bei Smartphones der Fall ist.

Bewusster Verstoß gegen das SRP

Viele Entwickler vertreten die Ansicht, dass bei Querschnittsaspekten gegen das SRP verstoßen werden sollte, da Querschnittsaspekte, wie das Logging, so nah wie möglich an der zuständigen Geschäftslogik sein sollten.

public sealed class PersonRepository : IPersonRepository
{
    private static ILogger Log = ...;

    public Person GetByName(string name)
    {
        try
        {
            return ...;
        }
        catch(Exception ex)
        {
            Log.Error(ex, $"Could not get Person named {name}");
            throw;
        }
    }
}

Das Logging direkt in der Methode führt allerdings dazu, dass das SRP nicht eingehalten und die Methode spaghettifiziert wird. Das Lesen und Testen der Geschäftslogik wird durch den Code des Aspekts erschwert.

Decorator-Methode

Eine Decorator-Methode ist eine einfache Möglichkeit, den Aspekt und die Geschäftslogik in getrennte Methoden auszulagern.

public sealed class PersonRepository : IPersonRepository
{
    private static ILogger Log = ...;

    public Person GetByName(string name)
    {
        try
        {
            return GetByNameWithoutLogging(name);
        }
        catch(Exception ex)
        {
            Log.Error(ex, $"Could not get Person named {name}");
            throw;
        }
    }

    private Person GetByNameWithoutLogging(string name)
    {
        return ...;
    }
}

Nachteilig ist, dass der Aspekt zwar auf Methodenebene ausgelagert wurde, allerdings weiterhin in der Klasse vorhanden ist. Dies stellt daher eine Verletzung des SRP auf Klassenebene dar. Zwar wird die Lesbarkeit verbessert, jedoch stellt sich beim Testen weiterhin die Herausforderung, dass der Aspekt mitgetestet werden muss.

Aspektorientierte Programmierung

Die Aspektorientierte Programmierung (AOP) stellt einen alternativen Ansatz dar, um den Aspekt auszulagern. Hierbei wird die Logik lediglich über eine Auszeichnung definiert und von einem Aspekt-Weaver implementiert.

public sealed class PersonRepository : IPersonRepository
{
    [LogToErrorOnException]
    public Person GetByName(string name)
    {
        return ...;
    }
}

Nachteilig ist hierbei, dass das SRP nicht eingehalten wird, da der Aspekt weiterhin in der Klasse verbleibt. Zudem können eventuell nicht alle Aspekte ausgegliedert werden. Beispielsweise kann im obigen Beispiel mit einem Attribut keine parametrisierte Fehlermeldung angegeben werden. Dies führt dazu, dass die Lösung an vielen Stellen annähernd dieselbe Komplexität aufweist wie die ursprüngliche Lösung:

public sealed class PersonRepository : IPersonRepository
{
    public Person GetByName(string name)
    {
        try
        {
            return ...;
        }
        catch(Exception ex)
        {
            LogTo.Error(ex, $"Could not get Person named {name}");
            throw;
        }
    }
}

Zudem befindet sich die Logik des Aspekt nach dem Kompiliervorgang weiterhin in der Klasse und erschwert daher weiterhin die Testbarkeit.

Unterklasse

Eine weitere Möglichkeit den Aspekt von der Geschäftslogik zu trennen besteht darin, abgeleitete Klassen einzuführen.

public class PersonRepository : IPersonRepository
{
    public virtual Person GetByName(string name)
    {
        return ...;
    }
}

public sealed class LoggingPersonRepository : PersonRepository
{
    private static ILogger Log = ...;

    public override Person GetByName(string name)
    {
        try
        {
            return base.GetByName(name);
        }
        catch(Exception ex)
        {
            Log.Error(ex, $"Could not get Person named {name}");
            throw;
        }
    }
}

Diese Lösung verstößt allerdings gegen das Prinzip Komposition an Stelle von Vererbung einzusetzen. Ein weiterer Nachteil ist, dass sämtliche Klassen und Methoden für Vererbung geöffnet werden müssen, wodurch zudem gegen das Open-Closed-Prinzip verstoßen wird.

Unterklassen zur Auslagerung von Aspekten stellen daher ein Antipattern dar.

Decorator

Aspekte lassen sich mittels eines Decorators realisieren und somit von der Geschäftslogik trennen.

public sealed class PersonRepository : IPersonRepository
{
    public Person GetByName(string name)
    {
        return ...;
    }
}

public sealed class PersonRepositoryLoggingFacade : IPersonRepository
{
    private static ILogger Log = ...;
    public IPersonRepository Repository { get; }

    public LoggingPersonRepository(PersonRepository repository)
    {
        Repository = repository;
    }

    public Person GetByName(string name)
    {
        try
        {
            return Repository.GetByName(name);
        }
        catch(Exception ex)
        {
            Log.Error(ex, $"Could not get Person named {name}");
            throw;
        }
    }
}

Der Vorteil hierbei ist, dass das Prinzip der Komposition an Stelle von Vererbung eingehalten wird. Die Klasse PersonRepository kann in Folge gegenüber Vererbung geschlossen werden, da eine Erweiterung durch Komposition jederzeit möglich ist. Ein weiterer Vorteil ist, dass der Aspekt durch eine Konfiguration der Dependency Injection ausgetauscht werden kann. Zudem kann die Logging-Logik unabhängig von der Business-Logik getestet werden.

Nachteilig ist allerdings ein höherer Wartungsaufwand, da in der Dependency Injection sowohl die Klasse mit der Geschäftslogik, als auch die Klasse mit dem Aspekt verwaltet werden muss. Durch die Trennung wird zudem die Nachvollziehbarkeit (z. B. in welcher Klasse ein Fehler aufgetreten ist) erschwert.