Namensräume

In einem der ersten Artikel haben wir kurz "Namespaces" (Namensräume) besprochen. Sie erkennen das Schlüsselwort wahrscheinlich, weil es in den meisten Dateien mit C# -Code gefunden wird, normalerweise fast ganz oben. Ein Namespace ist im Wesentlichen eine Möglichkeit, eine Menge von Typen zu gruppieren, z.B.: Klassen, in einem eigenen benannten Raum. Wenn Visual Studio ein neues Projekt für Sie generiert, generiert es außerdem einen Standardnamespace, in dem es Ihre erste Datei ablegt (zumindest gilt dies für den Projekttyp Console-App). Es könnte so aussehen:

using System;  

namespace MyProject  
{  
    class Program  
    {  
    static void Main(string[] args)  
    {  
        // More code below this....

In diesem Fall ist der Namespace "MyProject" und ein Teil der Anwendung und wenn Sie seine Klassen außerhalb davon verwenden, müssen Sie dem Klassennamen den Namen des Namespace voranstellen. Sie sehen genau das Gleiche, wenn Sie etwas tief in das .NET-Framework eingebettet verwenden möchten:

System.IO.File.ReadAllText("test.txt");

In diesem Fall verwenden wir die ReadAllText()-Methode in der Dateiklasse, die im System.IO -Namensraum vorhanden ist. Natürlich wäre es mühsam, jedes Mal, wenn Sie eine Klasse aus einem Namespace verwenden möchten, einen so langen Namen zu schreiben, sodass C# Ihnen erlaubt, einen ganzen Namespace mit einer using-Anweisung in den Bereich Ihrer Datei zu "importieren" . Vielleicht kennen Sie sie bereits, weil Sie sie normalerweise oben in Ihren C# -Dateien finden können. Wenn im obigen Beispiel die Dateiklasse mehr als einmal benötigt würde, wäre es sinnvoll, den Namespace System.IO mit einer using-Anweisung wie dieser zu importieren:

using System;
using System.IO;
// More using statements here...

Warum benötigt man Namensräume?

Wenn Sie gerade mit der Programmierung begonnen haben, fragen Sie sich vielleicht, wofür wir Namespaces benötigen. Warum sollten Sie nicht alle Klassen in denselben Namespaces platzieren, damit sie immer zugänglich sind? Das ist ein Argument, aber nur, wenn Ihr Projekt sehr klein ist. Sobald Sie beginnen, immer mehr Klassen hinzuzufügen, ist es sehr sinnvoll, diese in Namespaces zu unterteilen. Es erleichtert Ihnen die Suche nach Ihrem Code, insbesondere, wenn Sie Ihre Dateien in den entsprechenden Ordnern ablegen. Wenn Sie Ihrem Projekt einen Ordner und ihm dann eine Klasse hinzufügen, fügt Visual Studio diesen automatisch ein Namensraum hinzu. Wenn Sie also einen Ordner in MyProject namens MyFolder erstellen, werden Klassen, die diesem Ordner hinzugefügt wurden, standardmäßig in einem Namespace mit dem Namen MyProject.MyFolder plaziert.

Ein gutes Beispiel dafür, warum Namespaces benötigt werden, ist das .NET Framework selbst. Denken Sie nur, wenn ALLE Klassen im Framework nur in einem globalen Namensraum herumschweben würden - es wäre ein Durcheinander! Stattdessen haben Sie sie gut organisiert, mit System als Root-Namespace für die meisten Klassen und dann mit Sub-Namespaces wie System.IO für Ein- / Ausgabestationen, System.Net für netzwerkbezogenes Zeug und System.Net.Mail für Mail-bezogene Sachen.

Namenskonflikte mit "Namespaces".

Wie bereits erwähnt, sind Namespaces auch da, um Ihre Typen (normalerweise Klassen) einzukapseln, so dass sie in ihrer eigenen Domäne existieren können. Dies bedeutet auch, dass Sie Klassen mit dem gleichen Namen erstellen können, die Sie an anderer Stelle in Ihrem Projekt oder sogar im .NET-Framework finden. Sie könnten beispielsweise entscheiden, dass Sie eine eigene Dateiklasse benötigen. Wie wir in den vorherigen Beispielen gesehen haben, existiert eine solche Klasse bereits im System.IO-Namespace, aber Sie können einen in Ihrem eigenen Namespace wie folgt erstellen:

using System;  

namespace MyProject.IO  
{  
    class File  
    {  
    public static void HelloWorld()  
    {  
        Console.WriteLine("Hello, world!");  
    }  
    }  
}

Wenn Sie es jetzt in Ihrem Projekt verwenden möchten, z.B.: in Ihrer Hauptmethode Program.cs (wenn Sie an einer Konsolenanwendung arbeiten, wie ich), können Sie entweder den vollständigen Namen schreiben:

MyProject.IO.File.HelloWorld();

Sie können den Namespace aber auch wie jedes andere Namespace (eingebaut oder benutzerdefiniert) dank der using-Anweisung importieren. Hier ist ein vollständigeres Beispiel:

using System;
using MyProject.IO;

namespace MyProject
{
    class Program
    {
    static void Main(string[] args)
    {
        File.HelloWorld();
    }
    }
}

So weit, so gut! Was aber, wenn Sie auch die Dateiklasse aus dem Namespace System.IO verwenden möchten? Nun, hier beginnt der Fehler, denn wenn Sie diesen Namespace auch mit einer using-Anweisung importieren, weiß der Compiler nicht mehr, auf welche Dateiklasse Sie sich beziehen - unsere eigene oder die aus dem System.IO-Namespace. Dies kann dadurch gelöst werden, dass nur einer der Namespaces importiert wird (idealerweise der, aus dem Sie die meisten Typen verwenden) und dann der Name des anderen Namespaces vollständig qualifiziert wird, wie in diesem Beispiel:

using System;
using System.IO;

namespace MyProject
{
    class Program
    {
    static void Main(string[] args)
    {
        MyProject.IO.File.HelloWorld();
    }
    }
}

Es ist jedoch ein wenig umständlich, jedes Mal zu tippen, besonders wenn Ihre Klasse noch tiefer in Namespaces verschachtelt ist, z.B.: MyProject.FileStuff.IO.File. Zum Glück hat C# eine Lösung dafür.

Verwendung von Alias Direktiven

Um den Namen des Namensraums stark zu verkürzen, können Sie den Namensraum unter einem anderen Namen mit einer Alias-Direktive verwenden. Beachten Sie, wie ich genau das im nächsten Beispiel mache:

using System;
using System.IO;
using MyIO = MyProject.IO;

namespace MyProject
{
    class Program
    {
    static void Main(string[] args)
    {
        File.ReadAllText("test.txt");
        MyIO.File.HelloWorld();
    }
    }
}

Die Magie passiert in der dritten Zeile, wo ich den MyProject.IO-Namespace abrufe und ihm einen kürzeren Namen (MyIO) gebe, der dann verwendet werden kann, wenn wir auf Typen von ihm zugreifen wollen. An dieser Stelle speichern wir nicht viele Tastenanschläge, aber Sie sollten sich auch noch längere Namen und Ebenen von Namespaces vorstellen, und glauben Sie mir, sie können ziemlich lang und verschachtelt werden.

Zusammenfassung

Namespaces gibt Ihnen die Möglichkeit, Ihre Typen in "benannte Leerzeichen" einzubetten, wodurch Sie eine bessere Struktur in Ihrem Code erhalten und mehrere Klassen mit demselben Namen haben können, solange sie in separaten Namespaces existieren.