Kann eine Schnittstelle von einer Klasse abhängig sein?

Question

Ich untersuche SOLID-Prinzipien und habe eine Frage zum Abhängigkeitsmanagement in Bezug auf Schnittstellen.

Ein Beispiel aus dem Buch lese ich (Adaptive-Code über C# von Gary McLean Halle) zeigt eine TradeProcessor Klasse, die die Handelsdaten erhalten wird, verarbeiten und speichern sie in der Datenbank. Die Handelsdaten werden von einer Klasse namens TradeRecord modelliert. Eine TradeParser Klasse verarbeitet die erhaltenen Handelsdaten in eine TradeRecord Instanz (en). Die TradeProcessor Klasse verweist nur auf eine ITradeParser Schnittstelle, so dass sie nicht von der TradeParser Implementierung abhängig ist.

Der Autor hat die Parse Methode (in der ITradeParser Schnittstelle) eine IEnumerable<TradeRecord> Sammlung zurückgeben, die die verarbeiteten Handelsdaten enthält. Bedeutet das nicht, dass ITradeParser nun von der Klasse TradeRecord abhängig ist?

Sollte der Autor nicht etwas wie eine ITradeRecord Schnittstelle gemacht haben und Parse eine Sammlung von ITradeRecord Instanzen zurückgeben? Oder vermisse ich etwas Wichtiges?

Hier ist der Code (die Implementierung von TradeRecord ist irrelevant, so dass es weggelassen):

TradeProcessor.cs

public class TradeProcessor 
{ 
    private readonly ITradeParser tradeParser; 

    public TradeProcessor(ITradeParser tradeParser) 
    { 
     this.tradeParser = tradeParser; 
    } 

    public void ProcessTrades() 
    { 
     IEnumerable<string> tradeData = "Simulated trade data..." 
     var trades = tradeParser.Parse(tradeData); 

     // Do something with the parsed data... 
    } 
} 

ITradeParser.cs

public interface ITradeParser 
{ 
    IEnumerable<TradeRecord> Parse(IEnumerable<string> tradeData); 
} 

Answer 1

Dies ist eine gute Frage, die in den Kompromiss geht zwischen Reinheit und Praktikabilität.

Ja, von reinem Prinzipal, können Sie sagen, dass ITradeParser.Parse eine Sammlung von ITraceRecord Schnittstellen zurückgeben sollte. Warum binden Sie sich doch an eine bestimmte Implementierung?

Sie können dies jedoch weiter nehmen. Sollten Sie eine IEnumerable<string> akzeptieren? Oder sollten Sie eine Art von ITextContainer haben? I32bitNumeric anstelle von int? Dies ist reductio ad absurdum natürlich, aber es zeigt, dass wir immer irgendwann erreichen einen Punkt, an dem wir arbeiten etwas, ein konkretes Objekt (Nummer, String, TraceRecord, was auch immer), nicht ein Abstraktion.

Dies bringt auch den Punkt hervor, warum wir in erster Linie Schnittstellen verwenden, um Verträge für Logik und Funktionalität zu definieren. Ein ITradeProcessor ist ein Vertrag für eine unbekannte Implementierung, die ersetzt oder aktualisiert werden kann. A TradeRecord ist kein Vertrag für die Implementierung, es ist die Implementierung. Wenn es ein DTO-Objekt ist, was es zu sein scheint, würde es keinen Unterschied zwischen der Schnittstelle und der Implementierung geben, was bedeutet, dass es keinen wirklichen Zweck bei der Definition dieses Vertrags gibt - es ist in der konkreten Klasse enthalten.

Answer 2

Der Autor hat die Parse-Methode (in der ITradeParser-Schnittstelle) eine IEnumerable-Auflistung zurückgeben, die die verarbeiteten Handelsdaten enthält.

Bedeutet das nicht, dass ITradeParser jetzt von der TradeRecord-Klasse abhängig ist?

Ja, ITradeParser ist jetzt fest mit TradeRecord gekoppelt. Angesichts des eher akademischen Ansatzes dieser Frage kann ich sehen, woher Sie kommen. Aber was ist TradeRecord? Ein Datensatz ist per Definition im Allgemeinen ein einfaches, nicht intelligentes Datenelement (manchmal als POCO, DTO oder Model bezeichnet).

Irgendwann ist der potenzielle Gewinn der Abstraktion weniger wertvoll als die Komplexität, die er verursacht. Dieser Ansatz ist in der Praxis ziemlich üblich - Modelle (wie ich sie bezeichne) sind versiegelte Typen, die durch die Schichten einer Anwendung fließen. Schichten, die auf die Modelle einwirken, werden zu Grenzflächen abstrahiert, so dass jede Schicht getrennt dargestellt und getestet werden kann.

Zum Beispiel kann eine Client-Anwendung eine View-, ViewModel- und Repository-Ebene haben. Jede Schicht kann mit dem konkreten Datensatztyp arbeiten. Aber das ViewModel könnte so verkabelt werden, dass es mit einem verspotteten IRepository arbeitet, das die konkreten Typen mit fest codierten, gespotteten Daten aufbaut. Für ein abstrahiertes IModel gibt es an dieser Stelle keinen Vorteil - es hat nur gerade Daten.