.NET Buzz Forum - Verhalten einer Anwendung per Konfiguration bzw. Laufzeit verändern

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Abgrenzung

In diesem Artikel wird folgendes gezeigt:

Austauschen von Verhaltensweisen via Konfiguration als auch zur Laufzeit
Austauschen von einzelnen Methoden via Konfiguration als auch zur Laufzeit

Einführung

In vielen Fällen ist es notwendig, Verhaltensweisen über die Konfiguration oder per Laufzeit zu steuern. Als Beispiel: Nehmen wir eine Anwendung, die unterschiedliche Listen zur Verfügung stellt. Nun müssen die Daten für diese Listen geladen werden, damit sie angezeigt werden können. Unter der Annahme, dass alle Daten aus einer Datenbank kommen ist es kaum notwendig, dieses Verhalten zu verändern. Nun kann es aber sein, dass Inhalte für bestimmte Listen nicht aus der Datenbank kommen, sondern aus anderen Quellen. Das Standardverhalten würde nun nicht mehr funktionieren und muss daher ausgetauscht werden.
Ein weiterer häufig auftretender Punkt ist, dass zwar grundsätzlich das Standardverhalten verwendet werden soll, bis auf einen kleinen Teil, beispielsweise eine bestimmte Methode.

Strategy Pattern hilft bei Verhaltensänderungen

Da Verhaltensweisen getauscht werden können, liegt es nahe, sich im Bereich der Behavioral Patterns umzusehen. Darunter ist das Strategy-Pattern zu finden. Dieses ermöglicht, das gesamte Verhalten auszutauschen. Hier eine UML-Übersicht dieses Patterns:

Im Diagramm ist der Aufbau einfach zu erkennen. Grundsätzlich wird ein Interface IStrategy zur Verfügung gestellt. Dieses schreibt die Methode DoWork vor, welche dann die tatsächliche Aufgabe ausführt. Dieses Interface wird von zwei konkreten Klassen implementiert: ConcreteStrategy1 und ConcreteStrategy2. Beide Klassen besitzen also die Methode DoWork. Allerdings unterscheiden sich diese beiden Implementierungen voneinander, sprich das Verhalten ist ein unterschiedliches (sonst würde auch die Erstellung von zwei konkreten Klassen wenig sinnvoll sein). Schließlich gibt es noch einen StrategyContext. Dieser bekommt über den Konstruktor ein IStrategy übergeben. Dieses bestimmt nun das Verhalten. Die Aufrufe erfolgen über den StrategyContext, wodurch die Funktionalität aus dem übergebenen Strategy-Objekt aufgerufen wird. Eine Beispiel-Implementierung sieht so aus:

public interface IStrategy
{
    void DoWork();
}

public class ConcreteStrategy1 : IStrategy
{
    #region IStrategy Members

    public void DoWork()
    {
        Console.WriteLine("ConcreteStrategy1");
    }

    #endregion
}

public class ConcreteStrategy2 : IStrategy
{
    #region IStrategy Members

    public void DoWork()
    {
        Console.WriteLine("ConcreteStrategy2");
    }

    #endregion
}

public class StrategyContext
{
    private IStrategy _strategy;

    public StrategyContext(IStrategy strategy)
    {
        _strategy = strategy;
    }

    public void DoWork()
    {
        _strategy.DoWork();
    }
}

Der Aufruf des Konstruktes geschieht folgendermaßen:

class Program
{
    static void Main(string[] args)
    {
        StrategyContext context = new StrategyContext(new ConcreteStrategy1());
        context.DoWork();
    }
}

Austausch von einzelnen Methoden

Bisher haben wir gesehen, wie gesamte Verhaltensweisen ausgetauscht werden können. Wie sieht es jedoch aus, wenn nur einzelne Methoden getauscht werden und das restliche Verhalten gleich bleiben soll? Hier bietet sich ein Structural Pattern an, das Proxy Pattern. Dieses Pattern beschreibt einen möglichen Weg, wie Aufrufe an ein Ziel weitergeleitet werden können. Dies ist genau das was wir benötigen. Zuerst jedoch das UML Diagramm, um einen ersten Überblick zu erlagen:

Wie zu sehen ist, wird der StrategyContext gegen einen Proxy ersetzt. Dieser erhielt zusätzlich zur eigentlichen DoWork-Methode eine weitere Überladung, dem ein ICommand übergeben werden kann. Damit kann entweder das Standardverhalten (welches durch die konkrete Strategy-Implementierung vorgegeben wird) oder aber ein beliebiges eigenes Verhalten ausgeführt werden. Dies wirft natürlich die Frage auf, warum man nicht trotzdem ausschließlich mit dem Strategy-Pattern arbeiten kann. Der Einfachheit wegen hat dieses Beispiel nur eine einzige Methode, diese Variante kommt jedoch erst bei mehreren angebotenen Methoden zu tragen.
Hier eine Beispielimplementierung (IStrategy und die konkreten Implementierungen haben sich nicht geändert und sind im obigen Sourcecode zu finden):

public interface ICommand
{
    void Execute();
}

public class CustomWorker1 : ICommand
{
    #region ICommand Members

    public void Execute()
    {
        Console.WriteLine("CustomWorker1");
    }

    #endregion
}

public class CustomWorker2 : ICommand
{
    #region ICommand Members

    public void Execute()
    {
        Console.WriteLine("CustomWorker2");
    }

    #endregion
}

public class StrategyProxy
{
    private IStrategy _usedStrategy;

    public StrategyProxy(IStrategy usedStrategy)
    {
        _usedStrategy = usedStrategy;
    }

    public void DoWork()
    {
        _usedStrategy.DoWork();
    }

    public void DoWork(ICommand customWorker)
    {
        customWorker.Execute();
    }
}

Fazit

Dieser Beitrag hat gezeigt, wie gesamte Verhalten innerhalb einer Anwendung einfach ausgetauscht werden können bzw. einen Weg aufgezeigt, wie dies auf Basis von Methoden realisiert werden kann. Wer dies nun über eine Konfigurationsdatei konfigurieren möchte, der kann sich beispielsweise einen Builder basteln, welcher die Konfiguration ausliest und die darin angegebenen Typen mit Hilfe der Klasse Activator instanziert, den Proxy mit den notwendigen Instanzen füllt und ihn anschließend fertig konfiguriert zurück liefert.

Read: Verhalten einer Anwendung per Konfiguration bzw. Laufzeit verändern

Previous Topic

Next Topic


	Web Artima.com