Ich habe eine Komponente, die abhängig von der empfangenen Eingabe einen bestimmten Dienst aufrufen muss. Also muss meine Komponente die Eingabe ansehen und basierend auf einer Konfiguration, die besagt "für diesen eingehenden Anruf muss dieser Dienst mit diesen Daten" den richtigen Dienst aufrufen. Die Dienste haben eine gemeinsame Signaturmethode und eine spezifische (jeweils).
Ich habe über eine abstrakte Klasse nachgedacht, die die Signaturen für alle drei Methoden enthält. Die Implementierung für die beiden Dienste überschreibt alle drei Methoden (wobei NotImplementedException für die Methoden ausgelöst wird, die vom aktuellen Dienst nicht unterstützt werden). Eine Komponente, die mit einer Zuordnung initialisiert werden kann (die für jeden Eingabetyp den Typ des zu verwendenden Dienstes hat), wird ebenfalls definiert.
Haben Sie einen besseren Ansatz, um dieses Szenario zu bewältigen?
Factory-Muster hat diese Definition:
Definieren Sie eine Schnittstelle zum Erstellen eines Objekt, aber lassen Unterklassen entscheiden welche Klasse zu instanziieren. Fabrik Methode lässt eine Klasse zurückstellen Instanziierung in Unterklassen
Klingt wie du willst, oder?
Microsoft nennt dies das Designmuster für Anbietermodelle . Obwohl Ihre Methoden nicht alle Methoden implementieren, ist es vielleicht keine gute Lösung.
Auf der grundlegendsten Ebene ist das Muster:
Eine abstrakte Basisklasse, die a definiert Vertrag. Die abstrakte Basisklasse hat alle abstrakten Methoden und Eigenschaften, die für die Implementierung der öffentliche API wird unterstützt.
Konfigurationsinformationen. Einmal an Implementierung des Feature-Providers Klasse erstellt wird, muss beschrieben werden im Konfigurationsbereich. Die Beschreibung des Providers innerhalb der Konfiguration liefert alle Informationen, so dass der Provider in der laufenden Anwendung instanziiert werden kann.
Die abstrakte Basisklasse sollte normalerweise Factory-Methoden unterstützen, um neue Objekte zu erstellen.
Tags und Links c# design-patterns design factory