Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort zur 6. Auflage
1 Allgemeine Einführung in .NET
2 Grundlagen der Sprache C#
3 Das Klassendesign
4 Vererbung, Polymorphie und Interfaces
5 Delegates und Ereignisse
6 Strukturen und Enumerationen
7 Fehlerbehandlung und Debugging
8 Auflistungsklassen (Collections)
9 Generics – Generische Datentypen
10 Weitere C#-Sprachfeatures
11 LINQ
12 Arbeiten mit Dateien und Streams
13 Binäre Serialisierung
14 XML
15 Multithreading und die Task Parallel Library (TPL)
16 Einige wichtige .NET-Klassen
17 Projektmanagement und Visual Studio 2012
18 Einführung in die WPF und XAML
19 WPF-Layout-Container
20 Fenster in der WPF
21 WPF-Steuerelemente
22 Elementbindungen
23 Konzepte von WPF
24 Datenbindung
25 Weitere Möglichkeiten der Datenbindung
26 Dependency Properties
27 Ereignisse in der WPF
28 WPF-Commands
29 Benutzerdefinierte Controls
30 2D-Grafik
31 ADO.NET – Verbindungsorientierte Objekte
32 ADO.NET – Das Command-Objekt
33 ADO.NET – Der SqlDataAdapter
34 ADO.NET – Daten im lokalen Speicher
35 ADO.NET – Aktualisieren der Datenbank
36 Stark typisierte DataSets
37 Einführung in das ADO.NET Entity Framework
38 Datenabfragen des Entity Data Models (EDM)
39 Entitätsaktualisierung und Zustandsverwaltung
40 Konflikte behandeln
41 Plain Old CLR Objects (POCOs)
Stichwort

Download:
- Beispiele, ca. 62,4 MB

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Visual C# 2012 von Andreas Kühnel
Das umfassende Handbuch
Buch: Visual C# 2012

Visual C# 2012
Rheinwerk Computing
1402 S., 6., aktualisierte und erweiterte Auflage 2013, geb., mit DVD
49,90 Euro, ISBN 978-3-8362-1997-6
Pfeil 3 Das Klassendesign
Pfeil 3.1 Einführung in die Objektorientierung
Pfeil 3.2 Die Klassendefinition
Pfeil 3.2.1 Klassen im Visual Studio anlegen
Pfeil 3.2.2 Das Projekt »GeometricObjectsSolution«
Pfeil 3.2.3 Die Deklaration von Objektvariablen
Pfeil 3.2.4 Zugriffsmodifizierer einer Klasse
Pfeil 3.2.5 Splitten einer Klassendefinition mit »partial«
Pfeil 3.2.6 Arbeiten mit Objektreferenzen
Pfeil 3.3 Referenz- und Wertetypen
Pfeil 3.3.1 Werte- und Referenztypen nutzen
Pfeil 3.4 Die Eigenschaften eines Objekts
Pfeil 3.4.1 Öffentliche Felder
Pfeil 3.4.2 Datenkapselung mit Eigenschaftsmethoden sicherstellen
Pfeil 3.4.3 Die Ergänzung der Klasse »Circle«
Pfeil 3.4.4 Lese- und schreibgeschützte Eigenschaften
Pfeil 3.4.5 Sichtbarkeit der Accessoren »get« und »set«
Pfeil 3.4.6 Unterstützung von Visual Studio 2012
Pfeil 3.4.7 Automatisch implementierte Eigenschaften
Pfeil 3.5 Methoden eines Objekts
Pfeil 3.5.1 Methoden mit Rückgabewert
Pfeil 3.5.2 Methoden ohne Rückgabewert
Pfeil 3.5.3 Methoden mit Parameterliste
Pfeil 3.5.4 Methodenüberladung
Pfeil 3.5.5 Variablen innerhalb einer Methode (lokale Variablen)
Pfeil 3.5.6 Referenz- und Wertparameter
Pfeil 3.5.7 Besondere Aspekte einer Parameterliste
Pfeil 3.5.8 Zugriff auf private Daten
Pfeil 3.5.9 Die Trennung von Daten und Code
Pfeil 3.5.10 Namenskonflikte mit »this« lösen
Pfeil 3.5.11 Methode oder Eigenschaft?
Pfeil 3.5.12 Umbenennen von Methoden und Eigenschaften
Pfeil 3.6 Konstruktoren
Pfeil 3.6.1 Konstruktoren bereitstellen
Pfeil 3.6.2 Die Konstruktoraufrufe
Pfeil 3.6.3 Definition von Konstruktoren
Pfeil 3.6.4 »public«- und »internal«-Konstruktoren
Pfeil 3.6.5 »private«-Konstruktoren
Pfeil 3.6.6 Konstruktorenaufrufe umleiten
Pfeil 3.6.7 Vereinfachte Objektinitialisierung
Pfeil 3.7 Der Destruktor
Pfeil 3.8 Konstanten in einer Klasse
Pfeil 3.8.1 Konstanten mit dem Schlüsselwort »const«
Pfeil 3.8.2 Schreibgeschützte Felder mit »readonly«
Pfeil 3.9 Statische Klassenkomponenten
Pfeil 3.9.1 Statische Eigenschaften
Pfeil 3.9.2 Statische Methoden
Pfeil 3.9.3 Statische Klasseninitialisierer
Pfeil 3.9.4 Statische Klassen
Pfeil 3.9.5 Statische Klasse oder Singleton-Pattern?
Pfeil 3.10 Namensräume (Namespaces)
Pfeil 3.10.1 Zugriff auf Namespaces
Pfeil 3.10.2 Die »using«-Direktive
Pfeil 3.10.3 Globaler Namespace
Pfeil 3.10.4 Vermeiden von Mehrdeutigkeiten
Pfeil 3.10.5 Namespaces festlegen
Pfeil 3.10.6 Der »::«-Operator
Pfeil 3.10.7 Unterstützung von Visual Studio 2012 bei den Namespaces
Pfeil 3.11 Stand der Klasse »Circle«

Rheinwerk Computing - Zum Seitenanfang

3.10 Namensräume (Namespaces)Zur nächsten Überschrift

Die .NET-Klassenbibliothek enthält zahlreiche Klassendefinitionen, die dem Entwickler im Bedarfsfall ihre individuellen Dienste über Methoden bereitstellen. Es kann davon ausgegangen werden, dass sich das Angebot im Laufe der Zeit durch neue Technologien noch deutlich erweitern wird. Dabei sind die benutzerdefinierten Klassen noch nicht berücksichtigt.

Gäbe es für dieses große Angebot keine besondere Verwaltungsstruktur, wäre das Chaos perfekt. Erfahrene Entwickler wissen, wie schwierig es ist, aus den ca. 5.000 bis 6.000 verschiedenen Betriebssystemfunktionen eine bestimmte zu finden. Da hilft auch kein von Microsoft sorgfältig gewählter, beschreibender Funktionsname weiter: Die Suche gleicht dem Stöbern nach der berühmten Stecknadel im Heuhaufen. Dieser Problematik waren sich die .NET-Architekten bewusst und haben das Konzept der Namespaces (Namensräume) eingeführt. Namespaces sind hierarchische, logische Organisationsstrukturen. Sie kategorisieren Typdefinitionen, um das Auffinden einer bestimmten Funktionalität auf ein Minimum an Aufwand zu reduzieren und Mehrdeutigkeiten zu vermeiden.

Namespaces lassen sich sehr gut mit der Ordnerstruktur eines Dateisystems vergleichen. Dabei ähnelt ein Namespace einem Verzeichnis. Jedes Verzeichnis enthält Dateien, die meist logisch miteinander in Beziehung stehen: Beispielsweise können die Dateien eine Anwendung bilden, oder es handelt sich um gemeinsam verwaltete Benutzerdokumente. Innerhalb eines Namespaces werden ebenfalls logisch zusammenhängende Typen verwaltet. Beim Vergleich mit dem physikalischen Dateisystem entspricht eine Typdefintion einer Datei. Innerhalb eines Ordners muss der Name einer Datei eindeutig sein – innerhalb eines Namespaces gilt dasselbe für die Typbezeichner. Im Dateisystem können Verzeichnisse Unterverzeichnisse enthalten, um eine feinere Gliederung zu erzielen. Aus denselben Gründen können Namespaces weitere Namespaces einbetten.

Ein Namespace ist ein Verwaltungskonstrukt, in dem ein oder mehrere Typen logisch gruppiert werden, die funktional in einer verwandtschaftlichen Beziehung stehen. Beispielsweise sind alle Klassen des .NET-Frameworks, die Dateioperationen zur Verfügung stellen, dem Namespace System.IO zugeordnet. Der größte Namespace ist der mit der Bezeichnung System. Er enthält die wichtigsten .NET-Typen und hat aus organisatorischen Gründen weitere, untergeordnete Namespaces.

Zwischen einem Namespace und einer Bibliotheksdatei (DLL), die Typdefinitionen enthält, besteht keine 1:1-Beziehung. Vielmehr kann sich ein Namespace über mehrere DLLs erstrecken. Umgekehrt können in einer DLL-Datei auch mehrere Namespaces definiert werden.

Grundsätzlich ist jede Typdefinition Mitglied eines Namespaces. Folgerichtig wird auch jedweder Programmcode in Namespaces verwaltet. Jedes neue Projekt eröffnet dazu einen neuen Namespace, in dem alle Typen des aktuellen Projekts verwaltet werden.


Rheinwerk Computing - Zum Seitenanfang

3.10.1 Zugriff auf NamespacesZur nächsten ÜberschriftZur vorigen Überschrift

Es ist ein Irrtum zu glauben, man könne ohne weitere Maßnahme auf jeden beliebigen Namespace und eine darin verwaltete Klasse Zugriff erhalten. Vielmehr muss dem Projekt die Klassenbibliothek, die den gewünschten Namespace enthält, bekannt gegeben werden.

Damit jedes Projekt von Anfang an eine gewisse Grundfunktionalität hat, werden die wichtigsten Bibliotheken von Anfang an in jedes Projekt eingebunden. Sie finden die Liste der entsprechenden Dateiverweise im Projektmappen-Explorer, wenn Sie den Knoten Verweise öffnen. Die Dateiendung wird in der Verweisliste nicht mit angegeben (siehe Abbildung 3.6).

Abbildung

Abbildung 3.6 Der geöffnete Knoten »Verweise«

Damit stehen dem Entwickler bereits nach dem Anlegen eines neuen Projekts sehr viele Klassen zur Verfügung – nämlich die, die in den Bibliotheken enthalten sind, auf die verwiesen wird. Sollte es sich im Laufe der Entwicklungszeit herausstellen, dass darüber hinaus noch weitere benötigt werden, muss die Verweisliste mit den entsprechenden Bibliotheken ergänzt werden. Dazu öffenen Sie das Kontextmenü des Knotens Verweise im Projektmappen-Explorer und wählen Verweis hinzufügen.... Daraufhin wird das in Abbildung 3.7 dargestellte Dialogfenster Verweis-Manager angezeigt. In der Registerkarte .NET wird die gewünschte Datei markiert und über die Schaltfläche OK zur Liste der ausgewählten Komponenten hinzugefügt. In Tabelle 3.3 sind die Registerkarten des Dialogs erläutert.

Abbildung

Abbildung 3.7 Der Dialog zum Hinzufügen von Verweisen

Tabelle 3.3 Die Registerkarten des Dialogs »Verweis-Manager«

Registerkarte Beschreibung

Assemblies

Wenn diese Registerkarte aktiviert wird, werden weitere Untergruppen angezeigt: Framework, Erweiterungen und unter Umständen auch noch Aktuell. Unter Framework sind alle Bibliotheken zu finden, die das .NET Framework in der Ausgangslage zur Verfügung stellt. Unter Erweiterungen sind die Komponenten externer Anbieter zu finden, und in Aktuell findet man alle Verweise, die abweichend von der Projektvorlage hinzugefügt worden sind.

COM

Möchten Sie eine Komponente nutzen, die für COM/ActiveX entwickelt worden ist, suchen Sie die gewünschte Komponente hier.

Durchsuchen

Über diese Lasche können Sie zu einer Komponente im Dateisystem navigieren.

Projektmappe

Hier werden alle (kompatiblen) Projekte in der Projektmappe aufgelistet.

Wenn Sie wissen, welche Klasse Sie in Ihrem Projekt benötigen, stellt sich nur noch die Frage, in welcher Datei die Klasse zu finden ist. Die Lösung ist sehr einfach, wenn Sie sich das Datenblatt der entsprechenden Klasse in der .NET-Dokumentation ansehen. Darin werden Sie sowohl die Angabe des Namespaces finden, dem die Klasse zugeordnet ist, als auch die Angabe der zugehörigen Bibliotheksdatei.


Rheinwerk Computing - Zum Seitenanfang

3.10.2 Die »using«-DirektiveZur nächsten ÜberschriftZur vorigen Überschrift

Standardmäßig muss beim Zugriff auf eine Klasse auch der Namespace angeführt werden, dem die Klasse zugeordnet ist. Betrachten wir dazu das schon häufig benutzte Beispiel der Methode WriteLine der Klasse Console, die zum Namespace System gehört. Um im Konsolenfenster eine Ausgabe zu erhalten, müsste streng genommen

System.Console.WriteLine("Hallo Welt");

codiert werden. Eine Angabe, die aus Namespace und Klassenname besteht, wird als vollqualifizierter Name bezeichnet und ähnelt einer kompletten Pfadangabe im physikalischen Dateisystem. Vollqualifizierte Namen führen oft zu sehr langen, unübersichtlichen und schlecht lesbaren Ausdrücken im Programmcode, insbesondere wenn mehrere Namespaces ineinander verschachtelt sind. C# bietet uns mit der using-Direktive Abhilfe. Mit

using System;

kann an späterer Stelle im Programmcode auf alle Typen des so bekannt gegebenen Namespaces unter Angabe des Typbezeichners zugegriffen werden, ohne den vollqualifizierten Namen angeben zu müssen:

Console.WriteLine("Hallo Welt");

using-Direktiven stehen außerhalb der Klassendefinitionen und beziehen sich nur auf die Quellcodedateien, in denen sie angegeben sind.


Rheinwerk Computing - Zum Seitenanfang

3.10.3 Globaler NamespaceZur nächsten ÜberschriftZur vorigen Überschrift

In .NET gibt es einen sogenannten globalen Namespace. Diesem werden die folgenden Elemente zugeordnet:

  • alle Top-Level-Namespaces
  • alle Typen, die keinem Namespace zugeordnet sind

Der Zugriff auf den globalen Namespace unterliegt einer speziellen Syntax und wird in Abschnitt 3.10.5 erläutert.


Rheinwerk Computing - Zum Seitenanfang

3.10.4 Vermeiden von MehrdeutigkeitenZur nächsten ÜberschriftZur vorigen Überschrift

Namespaces dienen zur Strukturierung und Gruppierung von Klassen mit ähnlichen Merkmalen, aber auch zur Vermeidung von Mehrdeutigkeiten. Konflikte aufgrund gleicher Typbezeichner werden durch Namespaces vermieden. Allerdings kann die Bekanntgabe mehrerer Namespaces mit using Probleme bereiten, sollten in zwei verschiedenen Namespaces jeweils gleichnamige Typen existieren. Dann hilft using auch nicht weiter. Angenommen, in den beiden fiktiven Namespaces MyApplication und YourApplication wäre jeweils eine Klasse Person definiert, dann würde der folgende Code wegen der Uneindeutigkeit des Klassenbezeichners einen Fehler verursachen:

using MyApplication;
using YourApplication;
class Demo {
static void Main(string[] arr)
{
Person obj = new Person();
[...]
}
}

Die Problematik lässt sich vermeiden, wenn der Namespace der Klasse Person näher spezifiziert wird, beispielsweise mit:

MyApplication.Person person = new MyApplication.Person();

Es gibt auch noch eine weitere Möglichkeit, um den Eindeutigkeitskonflikt oder eine überlange Namespace-Angabe zu vermeiden: die Definition eines Alias. Während die einfache Angabe ohne Alias hinter using nur einen Namespace erlaubt, ersetzt ein Alias den vollständig qualifizierenden Typbezeichner. Damit könnte die Klasse Person in den beiden Namespaces auch wie folgt genutzt werden:

using FirstPerson = MyApplication.Person;
using SecondPerson = YourApplication.Person;
[...]
FirstPerson person = new FirstPerson();

Genauso können Sie, falls Sie Spaß daran haben, die Klasse Console »umbenennen«, z. B. in Ausgabe:

using Ausgabe = System.Console;
[...]
Ausgabe.WriteLine("Hallo Welt");

Rheinwerk Computing - Zum Seitenanfang

3.10.5 Namespaces festlegenZur nächsten ÜberschriftZur vorigen Überschrift

Jedem neuen C#-Projekt wird von der Entwicklungsumgebung automatisch ein Namespace zugeordnet. Standardmäßig sind Namespace- und Projektbezeichner identisch.

Solange sich Typen innerhalb desselben Namespaces befinden, können sie sich gegenseitig direkt mit ihrem Namen ansprechen. Die Klassen DemoA, DemoB und DemoC des folgenden Codefragments sind demselben Namespace zugeordnet und benötigen deshalb keine vollqualifizierte Namensangabe.

namespace MyApplication 
{
class DemoA {[...]}
class DemoB {{...]}
class DemoC {[...]}
}

Jeden Namespace können Sie selbstverständlich nach eigenem Ermessen benennen. Häufig verwenden die Unternehmen dazu ihren Unternehmensnamen. Zudem lassen sich auch mehrere Namespaces angeben, wie das folgende Listing zeigt:

using System;
using MyApp;
using ConsoleApplication;
namespace ConsoleApplication
{
class Program {
static void Main(string[] args)
{
// erfordert: using MyApp;
Demo obj = new Demo();
}
}
}
namespace MyApp
{
public class Demo
{
public void Test()
{
// erfordert: using ConsoleApplication;
Program obj = new Program();
}
}
}

Listing 3.50 Angabe mehrerer Namespaces

Das Beispiel zeigt die beiden parallelen Namespaces ConsoleApplication und MyApp. Jeder enthält eine Klasse mit einer Methode, in der ein Objekt vom Typ der Klasse aus dem anderen Namespace instanziiert wird. Da der Zugriff namespace-übergreifend ohne die Angabe des vollqualifizierten Bezeichners erfolgt, müssen beide Namespaces durch using bekannt gegeben werden.

Eingebettete Namespaces

Ein Namespace kann mit einem Ordner des Dateisystems verglichen werden. So wie ein Ordner mehrere Unterordner enthalten kann, können auch Namespaces eine hierarchische Struktur bilden. Der oberste Namespace, der entweder dem Projektnamen entspricht oder manuell verändert worden ist, bildet die Wurzel der Hierarchie, ähnlich einer Laufwerksangabe.

Soll dieser Stamm-Namespace eine feinere Strukturierung aufweisen und eingebettete Namespaces verwalten, wird innerhalb eines Namespaces ein weiterer, untergeordneter Namespace definiert:

namespace Outer {
class DemoA {
static void Main(string[] args) {

DemoB obj = new DemoB();
}
}
namespace Inner {
class DemoB
{
public void TestProc()
{/*...*/}
}
}
}

Listing 3.51 Verschachtelte Namespaces

Ein Typ in einem übergeordneten Namespace hat nicht automatisch Zugriff auf einen Typ in einem untergeordneten Namespace. Damit das Codefragment auch tatsächlich fehlerfrei kompiliert werden kann, ist es erforderlich, mit

using Outer.Inner;

den inneren Gültigkeitsbereich den Typen in der übergeordneten Ebene bekannt zu geben.


Rheinwerk Computing - Zum Seitenanfang

3.10.6 Der »::«-OperatorZur nächsten ÜberschriftZur vorigen Überschrift

Auch für Namespaces lässt sich ein Alias festlegen, beispielsweise:

using EA = System.IO;

Sie können nun wie gewohnt den Punktoperator auf den Alias anwenden, also:

EA.StreamReader reader = new EA.StreamReader("...");

Seit dem .NET Framework 2.0 bietet sich aber auch die Möglichkeit, mit dem ::-Operator auf Typen aus Namespace-Aliasen zu verweisen.

EA::StreamReader reader = new EA::StreamReader("...");

Die Einführung des ::-Operators hatte den Grund, unschöne Effekte zu vermeiden, die sich im Zusammenhang mit Namespace-Aliasen und dem Punkt-Operator ergeben können. Sehen Sie dazu den folgenden Beispielcode an:

using System;
using Document = Tollsoft.Developement.Office;
namespace ConsoleApplication {
class Program {
static void Main(string[] args) {
Document.Demo demo = new Document.Demo();
}
}
}
namespace Tollsoft.Developement.Office {
class Demo { }
}

Richten Sie Ihr Augenmerk auf die Anweisung in der Methode Main. Die Syntax Document.Demo lässt nicht eindeutig erkennen, ob es sich bei Document um einen Namespace handelt oder um einen Namespace-Alias. Zudem wäre auch noch denkbar, dass Demo eine innere Klasse von Document ist. Die Verwendung des ::-Operators würde zumindest demjenigen Entwickler eine Hilfe sein, der sich in den Quellcode neu einarbeiten muss. Besser wäre also die folgende Anweisung:

Document::Demo demo = new Document::Demo();

Noch bedeutender wird der ::-Operator, wenn in einer anderen Assembly, auf die im Projekt verwiesen wird, ein Namespace oder ein Typ mit dem gleichen Namen wie der Alias angeboten wird. Die Syntax Document.Demo würde dann sogar zu einem Fehler führen, während Document::Demo eindeutig ist.

Der ::-Operator gestattet auch den Zugriff auf den globalen Namespace. Das setzt nur die Voranstellung des C#-Schlüsselworts global voraus. Auf Typen, die Sie nicht explizit einem Namespace zugeordnet haben, können Sie auf diese Weise zugreifen (siehe Abbildung 3.8).

Man sollte diese Überlegung nicht einfach mit der Hand vom Tisch wischen, wenn aktuell kein Konflikt mit einem Namespace oder Typ in einer anderen Assembly vorliegt. Möglicherweise wird die Assembly, auf die verwiesen wird, später in einer neueren Version ausgeliefert. Spätestens dann könnte es zu einem Eindeutigkeitskonflikt kommen.

Abbildung

Abbildung 3.8 Der globale Namespace

Halten wir an dieser Stelle den Einsatz des ::-Operators fest:

  • Der ::-Operator ist notwendig, um mit Hilfe von global auf den globalen Namespace zuzugreifen.
  • Der ::-Operator sollte benutzt werden, um bei Verwendung eines Namespace-Alias kenntlich Eindeutigkeitskonflikte zu vermeiden.

Rheinwerk Computing - Zum Seitenanfang

3.10.7 Unterstützung von Visual Studio 2012 bei den NamespacesZur vorigen Überschrift

Mit dem Anlegen eines neuen Projekts gibt Visual Studio eine Reihe von Namespaces mit using an. Welche das sind, hängt von der Projektvorlage ab. Dabei sind Namespaces, die durchaus benötigt werden, aber auch solche, von denen angenommen wird, dass ein Entwickler sie vielleicht gebrauchen könnte.

Sie können die in einer Quellcodedatei nicht benötigten Namespaces mit Hilfe der Entwicklungsumgebung sehr einfach loswerden. Öffnen Sie dazu das Kontextmenü des Code-Editors, und wählen Sie hier Using-Direktiven organisieren. Anschließend können Sie entweder die nicht benötigten Direktiven löschen oder alle sortieren lassen (siehe Abbildung 3.9).

Ein ebenfalls sehr sinnvolles Feature ist das automatische Hinzufügen von benötigten using-Direktiven. Das setzt allerdings voraus, dass Sie die Klasse und natürlich auch deren Schreibweise hinsichtlich der Groß- und Kleinschreibung kennen. Geben Sie einfach den Klassenbezeichner im Editor ein, z. B. StreamReader. Anschließend setzen Sie den Mauscursor auf die Typangabe, öffnen das Kontextmenü und wählen hier auflösen. Sie können sich dann entscheiden, ob die entsprechende using-Direktive in den Kopf der Quellcodedatei geschrieben werden soll oder der Typ vollqualifizierend im Code angegeben wird (siehe Abbildung 3.10).

Abbildung

Abbildung 3.9 Verwalten der »using«-Direktiven in Visual Studio 2012

Abbildung

Abbildung 3.10 Unterstützung bei der Angabe der erforderlichen »using«-Direktiven



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Visual C# 2012

Visual C# 2012
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Professionell entwickeln mit Visual C# 2012






 Professionell
 entwickeln mit
 Visual C# 2012


Zum Rheinwerk-Shop: Windows Presentation Foundation






 Windows Presentation
 Foundation


Zum Rheinwerk-Shop: Schrödinger programmiert C++






 Schrödinger
 programmiert C++


Zum Rheinwerk-Shop: C++ Handbuch






 C++ Handbuch


Zum Rheinwerk-Shop: C/C++






 C/C++


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo





Copyright © Rheinwerk Verlag GmbH 2013
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern