JCB: Verschachtelte Klassen in Namespaces unterordnen

Hallo und guten morgen :)!

Ich hätt’ da gern mal ein Problem mit der Ein- bzw. unterordnung von Klassen in Namespaces. Es soll wie folgt aussehen:

Ich habe Projekt, welches folgende Klassen beinhaltet: ClassMain, Class1, Class2 und Class3. ClassMain soll
unter dem Namespace App.Usercontrols laufen (man soll also über App.Usercontrols.ClassMain auf diese Klasse zugreifen können).
Die Klassen Class1, Class2 und Class3 sind der Klasse ClassMain logisch untergeordnet (man soll also über
z.b.App.Usercontrols.ClassMain.Class1 auf Class1 zugreifen können). Jedoch möchte ich diese drei Klassen
der Übersicht wegen seperat speichern. Wenn ich aber die Namespaces wie folgt angebe, kommt es zu einem Namenskonflikt zwischen
dem Namespace und dem Klassennamen "ClassMain":

Namespace App.Usercontrols
   ClassMain
End Namespace

Namespace App.Usercontrols.ClassMain
   Class1
   Class2
   Class3
End Namespace

Wie kann ich also die Class1-3 logisch der Klasse ClassMain unterordnen, ohne sie z.B. innerhalb der Klasse ClassMain zu definieren?
Wahrscheinlich isses wieder ganz einfach. Wie immer ;).

Gruß
Jan

PS: Es handelt sich im Übrigen um ein VB.Net-Projekt, sollte aber eigentlich auf die Problematik keinen Einfluss haben.

  1. Tach!

    Habs dann doch selber hingekriegt ;). Aber es ist doch immer so. Wenn man sein Problem _schriftlich_ formuliert hat kommt man selber drauf :).

    Meine Problemlösung:

    Namespace App.Usercontrols

    ClassMain

    End Namespace

    Partial Public Class ClassMain

    Class1
    Class2
    Class3

    End Class

    Das wars :). Aber danke an alle die sich mein Posting durchgelesen haben ;). Geantwortet hat ja noch keiner ;).

    Gruß
    Jan

    1. Tach auch :)

      Warum müssen die 3 Klassen unbedingt _inline_ in der ClassMain sein? Das bringt quasi nirgendwo reale Vorteile mit sich.

      Du kannst sie auch einfach in einen entsprechenden Namespace einordnen. Aber der hat bei dir vielleicht dummerweise den Namen App.Usercontrols.ClassMain?

      Und du musst auch nicht alle Klassen als Public deklarieren. ;)

      Dein Beispiel ist zu "abstrakt" um dir eine konkrete Empfehlung geben zu können.

      Wenn du C# oder .Net oder von mir aus auch VB.Net in den Titel des Posting schreiben würdest, würde ich (und andere wahrscheinlich auch) wohl eher drüber stolpern.

      Cheers, Frank

      1. Tach Frank!

        Warum müssen die 3 Klassen unbedingt _inline_ in der ClassMain sein? Das bringt quasi nirgendwo reale Vorteile mit sich.

        Ok, ich hab die 3 Klassen _inline_ in ClassMain gesetzt, um sie im Namespace ClassMain zu haben. Anders hab ichs nicht hinbekommen. Für meine Belange auch vollkommen ausreichend. Wenn du mir sagst wie ich sie unter den gleichen Namespace krieg ohen Namenskonflikt bin ich
        dir dankbar :).

        Du kannst sie auch einfach in einen entsprechenden Namespace einordnen. Aber der hat bei dir vielleicht dummerweise den Namen App.Usercontrols.ClassMain?

        jo, das ist da Problem. Also folgendes noch zu Info. Unter dem Namespace App.Usercontrols hab ich mehrere eigene Steuerelemente.
        (App.Usercontrols.ctrlExtendedListview, App.Usercontrols.ctrlExtendedTextbox). Sofern jetzt diese Klassen/Controls keine weiteren eigenen Klassen verwenden gibts kein Problem mit dem für das Control verwendeten Namespace. Das Problem war ja die anderen Klassen in den gleichen Namespace zu kriegen bzw. dem Control unterzurodnen.

        Und du musst auch nicht alle Klassen als Public deklarieren. ;)

        Öhm, ok, wenn du mir sagst, wie ich auf z.B. private deklarierte Klassen von anderen Projekten aus zugreifen kann, dann streich ich das Public ;).

        Dein Beispiel ist zu "abstrakt" um dir eine konkrete Empfehlung geben zu können.

        Eigentlich spiegelt mein Beispiel genau mein Problem wieder.

        Wenn du C# oder .Net oder von mir aus auch VB.Net in den Titel des Posting schreiben würdest, würde ich (und andere wahrscheinlich auch) wohl eher drüber stolpern.

        Ok, jedoch ist das Problem ja ein OOP-Problem und nicht unbedingt auf die Prog-Sprache bezogen. Deshalb stand nix dabei. Das PS sollte lediglich als optionale Information dienen ;).

        Gruß
        Jan