using – ein Schlüsselwort voller Missverständnisse (EDT 02/13/10)

Bei Workshops und sonstigen Dialogen mit anderen Software-Entwicklern fällt mir immer wieder auf, dass es da Schlüsselworte gibt, mit denen die meisten nicht so wirklich was anfangen können. Aber es gibt auch welche, die sind vollkommen missverstanden. Eines davon ist using.

Dass es da Missverständnisse mit using gibt ist verständlich. Ist es doch eines der Worte mit doppelter, vollkommen unterschiedlicher Bedeutung.

using als Direktive

Sie kennen und nutzen using vermutlich einfach nur um Namespaces für die Verwendung in Ihrem Code einzubinden. Im oberen Teil Ihres Sourcecodes fügen Sie Zeilen wie

using System.Data;

ein, um Klassen und Methoden aus diesem Namespace nicht immer mit vollem Namen ansprechen zu müssen. So lässt sich das DataSet ab hier bequem mit dem Klassennamen ansprechen, wo sie vorher System.Data.DataSet verwenden mussten.

Using kann hier aber auch verwendet werden, um einen Alias für einen Namespace zu definieren. Das macht man gerne, falls es bei 2 eingebundenen Namespaces zu Namenskonflikten kommt. Mit

using DataNamespace = System.Data;

definieren Sie den Alias DataNamespace als Ersatz für System.Data. Ab hier können Sie das DataSet auch mit der Zeichenkette DataNamespace.DataSet ansprechen.

Weitere Infos darüber gibt’s natürlich bei MSDN.

using als  Anweisung

Wesentlich unbekannter scheint die Verwendung der Using-Anweisung zu sein. Sie erlaubt Ihnen die Einschränkung des Bereichs, in der bestimmte Ressourcen verwendet werden. Etwas konkreter: Sie können damit bestimmte Ressourcen gezielt ansprechen und wieder freigeben lassen – vollautomatisch sozusagen.

Sehr beliebt ist diese Vorgehensweise bei Objekten, die sie unbedingt per Dispose() wieder freigeben sollten. Das passiert nämlich bei using automatisch. Die verwendeten Klassen müssen dazu nur IDisposable implementieren.

using (FileStream stream = File.Open([dateiname]))
{
// Magic Code
}

Mit dieser Syntax wird beispielsweise eine Datei geöffnet, Sie wenden Ihren Code auf den Stream an und am Ende der Klammer wird automatisch ein Dispose() ausgeführt. Das absolut tollste daran: Das passiert auch im Exception-Fall. Wirft Ihr Code hier eine Ausnahme die Sie weiter oben im Stack abfangen, werden die Datei-Ressourcen hier trotzdem frei gegeben – ganz ohne try/catch/finally.

Sie können sich vorstellen, dass dieses Konstrukt sehr beliebt ist bei all den relativ instabilen Zugriffsobjekten wie Dateien, Datenbanken, COM-Objekten,…

Mehr dazu auf MSDN.