Ein Unterschied im Stil: IDictionary vs. Dictionary

Question 1

Ich habe einen Freund, der gerade erst in die .NET-Entwicklung einsteigt, nachdem er jahrelang in Java entwickelt hat, und nachdem ich mir einige seiner Codes angesehen habe, stelle ich fest, dass er ziemlich oft Folgendes tut:

IDictionary<string, MyClass> dictionary = new Dictionary<string, MyClass>();

Er deklariert das Wörterbuch als Schnittstelle und nicht als Klasse. Normalerweise würde ich folgendes tun:

Dictionary<string, MyClass> dictionary = new Dictionary<string, MyClass>();

Ich würde die IDictionary-Schnittstelle nur verwenden, wenn sie benötigt wird (z. B. um das Wörterbuch an eine Methode zu übergeben, die eine IDictionary-Schnittstelle akzeptiert).

Meine Frage ist: Hat seine Art, Dinge zu tun, irgendwelche Vorzüge? Ist dies eine gängige Praxis in Java?

Question 2

Wenn IDictionary ein “generischerer” Typ als Dictionary ist, ist es sinnvoll, den allgemeineren Typ beim Deklarieren von Variablen zu verwenden. Auf diese Weise müssen Sie sich nicht so sehr um die Implementierungsklasse kümmern, die der Variablen zugewiesen ist, und Sie können den Typ in Zukunft einfach ändern, ohne viel folgenden Code ändern zu müssen. Zum Beispiel wird es in Java oft als besser angesehen

List<Integer> intList=new LinkedList<Integer>();

als es zu tun ist

LinkedList<Integer> intList=new LinkedList<Integer>();

Auf diese Weise bin ich sicher, dass der gesamte folgende Code die Liste als Liste und nicht als LinkedList behandelt, was es in Zukunft einfach macht, LinkedList für Vector oder jede andere Klasse, die List implementiert, auszutauschen. Ich würde sagen, das ist Java und guter Programmierung im Allgemeinen gemeinsam.

Question 3

Diese Praxis ist nicht nur auf Java beschränkt.

Es wird auch häufig in .NET verwendet, wenn Sie die Instanz des Objekts von der verwendeten Klasse entkoppeln möchten. Wenn Sie die Schnittstelle statt der Klasse verwenden, können Sie den Unterstützungstyp jederzeit ändern, ohne den Rest Ihres Codes zu beschädigen.

Sie werden auch feststellen, dass diese Vorgehensweise häufig beim Umgang mit IoC-Containern und der Instanziierung mithilfe des Factory-Musters verwendet wird.

Question 4

Ihr Freund folgt dem sehr nützlichen Prinzip:

“Abstrahieren Sie sich von Implementierungsdetails”

Question 5

Sie sollten immer versuchen, die Schnittstelle und nicht die konkrete Klasse zu programmieren.

In Java oder einer anderen objektorientierten Programmiersprache.

In der .NET-Welt ist es üblich, eine zu verwenden I um anzuzeigen, dass es sich um eine Schnittstelle handelt, die Sie verwenden. Ich denke, das ist häufiger, weil sie es in C# nicht haben implements und extends um auf die Vererbung von Klasse und Schnittstelle zu verweisen.

Ich denke, Whey würde tippen

 class MyClass:ISome,Other,IMore 
 { 
 }

Und das merkt man ISome ein IMore sind Schnittstellen während Other ist eine Klasse

In Java ist so etwas nicht nötig

 class MyClass extends Other implements Some, More {
 }

Das Konzept gilt immer noch, Sie sollten versuchen, die Schnittstelle zu programmieren.

Question 6

Für lokale Variablen und private Felder, die bereits Implementierungsdetails sind, ist es besser, konkrete Typen als Schnittstellen für die Deklarationen zu verwenden, da die konkreten Klassen einen Leistungsschub bieten (direkter Versand ist schneller als virtueller/Schnittstellenversand). Das JIT kann Methoden auch einfacher inline integrieren, wenn Sie in den lokalen Implementierungsdetails nicht unnötig in Schnittstellentypen umwandeln. Wenn eine Instanz eines konkreten Typs von einer Methode zurückgegeben wird, die eine Schnittstelle zurückgibt, erfolgt die Umwandlung automatisch.

Question 7

Am häufigsten sehen Sie den Schnittstellentyp (IDictionary), der verwendet wird, wenn der Member für externen Code verfügbar gemacht wird, unabhängig davon, ob sich dieser außerhalb der Assembly oder direkt außerhalb der Klasse befindet. In der Regel verwenden die meisten Entwickler den konkreten Typ intern für eine Klassendefinition, während sie eine gekapselte Eigenschaft mithilfe des Schnittstellentyps verfügbar machen. Auf diese Weise können sie die Fähigkeiten des konkreten Typs nutzen, aber wenn sie den konkreten Typ ändern, muss sich die Schnittstelle der deklarierenden Klasse nicht ändern.

public class Widget
{
    private Dictionary<string, string> map = new Dictionary<string, string>();
    public IDictionary<string, string> Map
    {
        get { return map; }
    }
}

später kann werden:


class SpecialMap<TKey, TValue> : IDictionary<TKey, TValue> { ... }

public class Widget
{
    private SpecialMap<string, string> map = new SpecialMap<string, string>();
    public IDictionary<string, string> Map
    {
        get { return map; }
    }
}

ohne die Benutzeroberfläche des Widgets zu ändern und anderen Code, der es bereits verwendet, ändern zu müssen.

Question 8

Soweit ich gesehen habe, verwenden Java-Entwickler häufiger Abstraktion (und Entwurfsmuster) als .NET-Entwickler. Dies scheint ein weiteres Beispiel dafür zu sein: Warum die konkrete Klasse deklarieren, wenn er im Wesentlichen nur mit den Schnittstellenmitgliedern arbeiten wird?