Aus der C++-Ecke: Trennung Schnittstelle/Implementation

hi!

Ich bin eigentlich C++-Programmierer, muss aber C# lernen. Soweit kein Ding, bekomme das meiste selbst hin. http://www.galileocomputing.de/openbook/csharp/ Hilft mir dabei

Aber ich würde gerne eine logische Trennung "Header/cpp" vornehmen.
Wie macht man soetwas in C#? Ein kleines Beispiel wäre toll!

In der Klassendefinition sollen nur die Schnittstellen der Methoden zu sehen sein

Das macht man in C# nicht. Die hochgelobte "Trennung" zwischen Schnittstelle und Implementierung ist in C++ auch nur optischer Natur und technisch bedingt. Du hast damit keine echte Trennung, die die Compilierung zwischen den Programmteilen abkapselt. Für echte Schnittstellen zwischen verschiedenen Software-Komponenten benutzt man in C# Interfaces. Ich würde dir allerdings dringend davon abraten, die Interfaces als "Header"-Datei zu sehen.

Wie ist das denn unter C# üblich?

Jede Klasse eine eigene *.cs-Datei?

Irgendwie muss das ja organisiert werden.
Und ist es unter C# ebenfalls verwerflich, using System.Bla zu benutzen, sprich Namensräume zu öffnen?
Ich persönlich würde das nämlich wie bei C++ halten.

cin

Üblich ist es sicherlich eine Datei pro Klasse zu haben. Es stellt aber auch kein Problem da mehrere Klassen in eine Datei zu packen. Das ist Geschmackssache.

Zu den Namespaces:
Die Namespaces sind ja nicht mehr wirklich mit denen von C++ zu vergleichen. Wenn man in C# ein Namespace öffnet, stellt man der Datei die Funktionen/Klassen zur verfügung, die sich in eben diesem Namespace befinden. In etwa zu vergleichen mit dem #include<> aus C++. Es ist im Prinzip eine Mischung aus #include und using...

Ich für meinen Teil benutze immer die using-Direktive am Dateianfang. Da ich pro Datei nur eine Klasse implementiere, gibt es auch normal keine Probleme mit Namenskonflikten. Und den Fehler, dass man namespaces in Header-Dateien öffnet, kann ja auch nicht mehr passieren

Tequilla

Seit C# V2 ist es auch möglich eine Klasse in mehreren Dateien aufzuteilen.

Stichwort: partial class

Was meiner Ansicht eingentlicher Totalschrott ist, aber das ist Geschmacksache, und über die lässt sich ja bekanntlich ....

Polofreak

Hm da gabs aber schon Anwendungsfälle wo das Sinn gemacht hat. Ich war auch der Meinung was für ein Schrott, aber ein Prof hatte dann ein gutes Beispiel wo das echt Sinn gemacht hat.
Nur leider weiß ich es nichtmehr

cin schrieb:

In etwa zu vergleichen mit dem #include<> aus C++. Es ist im Prinzip eine Mischung aus #include und using...

Nein, aber echt nicht. using hat mit #include gar nichts zu tun. #include ist notwendig, damit ein Programm compiliert, using braucht man theoretisch nie.

Um in C++ zu sprechen:
Das using von C# lässt sich als typedef verwenden:

using Foo = Namespace1.Namespace2.Bar;

und als using namespace:

using System.Windows.Forms;

Tequilla schrieb:

Stichwort: partial class

Was meiner Ansicht eingentlicher Totalschrott ist, aber das ist Geschmacksache, und über die lässt sich ja bekanntlich ....

Das macht immer dann Sinn, wenn man Tools hat, die einen Teil deines Codes generieren. Extrem häufig kommt sowas bei der Arbeit mit Datenbanken oder GUIs vor. Um zu verhindern, dass das Tool deine eigenen Ergänzungen immer wieder überschreibt, kann man eine Datei dem Tool lassen und eine kann man selber bearbeiten.

cin schrieb:

Zu den Namespaces:
Die Namespaces sind ja nicht mehr wirklich mit denen von C++ zu vergleichen. Wenn man in C# ein Namespace öffnet, stellt man der Datei die Funktionen/Klassen zur verfügung, die sich in eben diesem Namespace befinden. In etwa zu vergleichen mit dem #include<> aus C++. Es ist im Prinzip eine Mischung aus #include und using...

Also fällt die komplette Makrogeschichte weg?
Registriert z.B. mein VisualStudio, welche Namespaces ich angelegt habe und macht sie so in jeder Datei, wo ich sage "using MeinNamespace" verfügbar?
Sprich, das using ersetzt indirekt das "include"?

cin schrieb:

Ich für meinen Teil benutze immer die using-Direktive am Dateianfang. Da ich pro Datei nur eine Klasse implementiere, gibt es auch normal keine Probleme mit Namenskonflikten. Und den Fehler, dass man namespaces in Header-Dateien öffnet, kann ja auch nicht mehr passieren

Sind die einzelnen Dateien wirklich für sich geschlossene Elemente? Also nicht, dass ich in einer Datei sage using System.x und dann gibt's in einer anderen 300 Fehler? Sowas kann gar nicht mehr passieren?

Polofreak

Ich meine dir komplett recht geben zu könenn aber warten wir mal was die Profis dazu sagen

@Ahhhhhhh: Das #include gibt es nicht mehr und auch nichts vergleichbares. Die Information, was verfügbar ist kommt über die Metadaten der referenzierten Assemblies rein. Das Linking findet ohnehin erst zur Laufzeit statt. Lies mal meinen Beitrag auch, cin liegt in diesem Punkt ziemlich falsch.

Ok, ich danke euch, besonders Optimizer, für eure Hilfe.