Bezeichnung für Namespace und Klasse / Problem bei Gleichheit

Hallo zusammen,

folgende Situation:

Ich habe eine (fiktive) Klasse TestButton.
Diese befindet sich in dem (fiktiven) Namespace PeterLustig.TestButton.Core

Binde ich diesen Namespace in irgendeine Codedatei ein, so kann ich die Klasse TestButton dennoch nur über ihren vollqualifizierten Namen ansprechen, da die IDE bzw. der Compiler sonst anscheinend Klasse und Namespace nicht unterscheiden kann.

Benenne ich den Namespace um, in bspw. PeterLustig.TestButton_NS_.Core, so funktioniert der Zugriff ganz simpel über den Klassennamen.

Fazit: Ist der Name einer Klasse ein Teil des Namens ihres Namespaces, so lässt sich die Klasse ausschließlich über ihren vollqualifizierten Namen ansprechen.

Ich hätte jetzt zuerst dazu tendiert, den Namespace dann einfach abzukürzen, bspw so PeterLustig.TB.Core, allerdings habe ich im guide to C# gelesen, dass man das nicht machen sollte.

Wie handhabt Ihr das? Wie bezeichnet Ihr Eure Namensräume und die dort enthaltenen Klassen?

Hi,

Die Namensräume bekommen bei mir meistens die Mehrzahl, da Sie ähnliche Klassen zusammen fassen oder bekommen den Namen der gemeinsamen Aufgabe der zusammengefassten klassen.

Bsp.-Namespace: Abrechnung.StatistischeMethoden
Bsp.-Klasse: Abrechnung.StatistischeMethoden.SummeStatistischeMethode

Gruß
Juy Juka

Gleichheit der Namespaces würde ich aus den oben genannten pragmatischen gründen schon vermeiden.

Ansonsten komme ich auch eher selten dahin dass ich überhaupt da etwas gleiches vergeben möchte.

Namespaces sind für mich Oberbegriffe, Sinnzusammen Hänge oder Abstraktionen..

Mehrzahl vermeide ich bei den Namespaces namen da man solche auch im .NET Framework selbst nicht antrifft, ist aber wohl geschmackssache 🙂.

Hallo Ihr beiden,

vielen Dank für Eure Antworten.

@JuyJuka
Das mit der Mehrzahl finde ich auf den ersten Blick recht gut 👍

@Haggy
Klar, ein Namensraum soll einen Oberbegriff darstellen.
In meinem aktuellen Beispiel ist es in der Tat so, dass ich ein Steuerelement mit dem (Pseudonamen) TestButton erzeugen möche.

Da dieses Steuerelement das grundlegende (bzw. das einzige) Element dieses Namespace ist, sollte der Name der Klasse schon mit in den Namespace integriert werden. Wegen der Gleichheit, bietet es sich da doch an, einfach ein 's' anzuhängen.

Klar, bei einer komplexen Anwendung, hat man mehrere Möglichkeiten.

Ich bin für weitere Vorschläge offen 😉

Hallo s-sharp,

ein Namespaces pro Klasse führt schnell zu einer Inflation und sollte die Ausnahme bleiben. Insofern ist der Rat von Haggy mindestens zu wichtig und nützlich wie der von JuyJuka. Schau mal ins Framework. Ich denke, da ist ein Namespace für eine einzelne Klasse eher die Ausnahme, falls es sowas überhaupt gibt. Selbst wenn die Klasse noch die einzige ist, wäre es daher sinnvoll, den Namespace nicht wie die Klasse zu benennen, sondern nach einem Oberbegriff (der auch auf Klassen, die man später hinzufügen könnte, passt). In deinem Fall also z.B. PeterLustig.Controls.Core.

herbivore

System.Configuration.Assemblies mit einer klasse und 2 enums
System.Deployment.Internal mit 2 klassen
System.Diagnostics.CodeAnalysis mit 1 klasse
System.Runtime.InteropServices.Expando mit nur einem interface
System.Runtime.Remoting.Services mit 2 klassen und einem interface
System.Configuration.Internal mit nur einer klasse
System.Web.Administration eine klasse
System.Web.Configuration.Common eine klasse
System.Web.Configuration.Internal ein interface
System.Collections.Specialized eine klasse

alles im allen sind es doch ausnahmen wenn man bedenkt das das framework verdammt viele namespaces hat.

Hallo JAck30lena,

und selbst bei diesen wenigen Namespaces eine Bestätigung der Regel, dass ein echter Oberbegriff und nicht einfach nur die Mehrzahl des Klassennamens verwendet wird.

herbivore

ein Namespaces pro Klasse führt schnell zu einer Inflation und sollte die Ausnahme bleiben.

Ich habe ja nicht gesagt, das ich einen Namespace je Klasse habe.

Wenn ich aber ein Steuerelement entwickle, dann ist der Name des Steuerelementes halt der Klassenname. Und da es das Basisobjekt ist, möchte ich, dass so (oder so ähnlich) auch der Namespace heißt.

Natürlich habe ich dann noch mehrere Klassen und Enums in diesem Namespace.

Wie würdet Ihr denn Euren Namespace und die Klasse benennen, wenn Ihr ein Steuerelement von 'Button' ableitet?

Hallo s-sharp,

Wie würdet Ihr denn Euren Namespace und die Klasse benennen, wenn Ihr ein Steuerelement von 'Button' ableitet?

In deinem Fall also z.B. PeterLustig.Controls.Core.

🙂

herbivore

klasse:
<funktion oder markante bezeichnung>Button

beispiel:
ImageButton
VerticalButton
AnimationButton

basisklasse:
<funktion oder markante bezeichnung><evtl noch ableitungsinformation>Base

beispiel (mit textbox):
HighlightingTextboxBase
AnimationTextboxBase

namespace für die genannten klassen wäre bei mir z.b.
<firmenname>.GUI.Controls

wobei das mit den namespaces immer recht differenziert zu betrachten ist, da es zu viele individuelle entscheidungsfaktoren gibt.

Danke für Eure Beispiele! Das bringt mich schon um einiges weiter!

Und danke für den Smiley 😉

Noch als Anmerkung: FxCop meckert übrigens Namespaces an, die genauso heißen wie in ihnen enthaltene Typen - ist also auch nach MS-Richtlinien kein guter Stil.

Okay, danke für den ergänzenden Hinweis 🙂

Habe es mit den Namensräumen nun, dank der oben genannten Beispiele, so gelöst:

für visuelle Controls:
meinname.gui.controls

für nicht visuelle Klassen (hier z.b. eine Klasse, die einen Bruch zeichnen kann)
meinname.nongui.classes.math

für Anwendungen (da ich daraus ggf. auch mal ein Steuerelement, AddOn o.ä machen könnte, ein separater Namespace für Anwendungen):
meinname.application.anwendungsname

Diese Namespaces werden auf der Festplatte dann in einer Verzeichnisstruktur abgebildet in denen sich dann alle *.cs-Dateien befinden; für jede Klasse eine.

vielleicht noch ein verbesserungsvorschlag:

meinname.nongui.classes.math

umbenennen in
meinname.gui.classes.math
da diese klasse ja zeichnet und somit zur gui gehört. alles was etwas grafisch darstellen kann, gehört zur gui, auch wenn es keine controls sind. da es kein control ist, grenzt du es logisch durch den namensraum ab.

Hallo s-sharp,

"Classes" finde ich etwas zu allgemein für einen Namespace-Namen. Auch "GuiClasses" und "NonGuiClasses" ist noch ziemlich allgemein. Du solltest spezifischere Namen wählen.

Zu sagen welche spezifischeren Namen besser wären, finde ich aber schwierig, ohne die Klassen zu kennen, die in dem jeweiligen Namespace sollen.

herbivore

Guten Morgen,

meinname.nongui.classes.math
umbenennen in
meinname.gui.classes.math

Klingt logisch 😉

"Classes" finde ich etwas zu allgemein für einen Namespace-Namen. Classes ist nur ein Container für einen weiteren Namespace, d.h. es wird keine Klasse geben, die direkt im Namespace Classes stehen wird; es wird immer noch einen weiteren, klassenspezifischen Subnamespace geben, wie bspw. hier math.

Ich dachte, ich könnte so eine ganz nette Abgrenzung finden.*gui.controls.math = Steuerelemente aus dem mathematischen Bereich; z.B. eine Matrix *gui.controls.graphics = Steuerelemente aus dem grafischen Bereich; z.B. eine spezielle PaintBox

*gui.applications.math = Anwendungen aus dem mathematischen Bereich; z.B. ein Formelrechner *gui.applications.graphics = Steuerelemente aus dem grafischen Bereich; z.B. ein Zeichenprogramm

*gui.classes.math = Klassen, die mathematische Funktionen zur Verfügung stellen; z.B. eine Klasse, die in der Lage ist, einen Bruch auf irgendein Control zu zeichnen *gui.classes.graphics = Klassen, die grafische Funktionen zur Verfügung stellen; z.B. eine Klasse, die in der Lage ist, einen Gradienten auf irgendein Control zu zeichnen

*gui.addons.vs = AddOns für das Visual Studio *gui.addons.office.outlook = AddOns für Outlook *gui.addons.office.word = AddOns für Word

*nongui.classes.strings = nicht-visuelle Klassen, die mit der Verarbeitung von String zu tun habe; z.B. eine Klasse, die in der Lage ist, einen String rückwärts wiederzugeben *nongui.classes.files = nicht-visuelle Klassen, die mit der Verarbeitung von Dateien zu tun haben

... etc.

Damit hatte ich mich eigentlich schon angefreundet; bin natürlich für weitere Vorschläge offen.

(Ich denke, einen perfekten Weg gibt es sowieso nicht, und den für sich selber am besten geeigneten Weg findet man im Laufe der Zeit von alleine. Nur möchte ich nicht irgendwann dastehen, und merken, dass ich mich bzgl. der Namespaces vollkommen verrannt habe; denn so einfach lässt sich ein solch essentielles Problem dann ja nicht wieder korrigieren. Deswegen möchte ich soviel von Eurer Erfahrung aufnehmen, wie eben möglich - danke!)

nongui.classes.strings = nicht-visuelle Klassen, die mit der Verarbeitung von String zu tun habe; z.B. eine Klasse, die in der Lage ist, einen String rückwärts wiederzugeben
nongui.classes.files = nicht-visuelle Klassen, die mit der Verarbeitung von Dateien zu tun haben

Hallo,

ich würde diese namespaces so benennen

• Text.Classes.Strings
• IO.Classes.Files

Alles was NonGUI ist, benenne ich immer in diesen "Obergruppen". Also IO, Text, Data. Ich halte mich ziemlich stark an den Bezeichnungen von MS.
Deswegen sehen meine Namespaces meist so aus

• xxx.Data;
• xxx.Data.Contracts;
• xxx.IO;
• xxx.Windows.Forms;
  usw...

Die IDE verrennt sich auch nicht (Intellisense), da der erste Teil des Namespaces sich ja unterscheidet.

nongui.classes.strings = nicht-visuelle Klassen, die mit der Verarbeitung von String zu tun habe; z.B. eine Klasse, die in der Lage ist, einen String rückwärts wiederzugeben
nongui.classes.files = nicht-visuelle Klassen, die mit der Verarbeitung von Dateien zu tun haben
Hallo,

ich würde diese namespaces so benennen

• Text.Classes.Strings
• IO.Classes.Files

Das war es wahrscheinlich auch, was herbivore meinte mit 'NonGui' sei ihm zu oberflächlich 😉

Danke 👍

So, nachdem ich nun die Namensräume umgestellt habe, tut sich doch noch eine Frage auf.

(das Folgende ist nur ein Beispiel!)

Angenommen ich habe ein Steuerelement TestButton1 programmiert.
Das Projekt enthält den Namespace MeinName.GUI.Controls.
Der Name meiner Assembly lautet MeinName.GUI.Controls.TestButton1
Innerhalb dieses Namespace ist meine Klasse TestButton1 deklariert.
Desweiteren ist innerhalb dieses Namespace eine Enumeration deklariert, die ich Sichtbarkeit nenne.

So, nun erstelle ich irgendwann ein zweites Steuerelement TestButton2, was mit TestButton1 nichts zu tun hat (also nicht abgeleitet werden kann).
Auch dieses Projekt enthält den Namespace MeinName.GUI.Controls, da es sich ja ebenfalls um ein Control handelt.
Der Name meiner Assembly lautet dementsprechend MeinName.GUI.Controls.TestButton2
Innerhalb dieses Namespace ist meine Klasse TestButton2 deklariert.
Desweiteren benötigt auch dieses Steuerelement innerhalb dieses Namespace eine Enumeration Sichtbarkeit. Diese Enumeration hat allerdings andere Werte, als die Enumeration Sichtbarkeit von TestButton1.

So, und nun das Problem.
Ich erzeuge eine Anwendung, die die beiden oben genannten Steuerelemente TestButton1 und TestButton2 einsetzt.
Also füge ich den Verweisen die beiden DLLs MeinName.GUI.Controls.TestButton1.dll und MeinName.GUI.Controls.TestButton2 hinzu.

Möchte ich nun auf die Enumeration Sichtbarkeit von TestButton2 zugreifen, ist dieses logischerweise nicht möglich, da der Bezeichner Sichtbarkeit zuerst im Namespace MeinName.GUI.Controls der Assembly MeinName.GUI.Controls.TestButton1.dll gefunden wird.

Im Prinzip könnte man doch nun sagen, dass dieses Problem auftritt, da die Bezeichnung des Namespace mit MeinName.GUI.Controls zu allgemein gewählt ist, oder?

Würde der Namespace für TestButton1 so heißen: MeinName.GUI.Controls.TestButton1 und der für TestButton2 dementsprechend MeinName.GUI.Controls.TestButton2, so könnte ich bequem auf die Enumerationen beider Assemblies zugreifen.

Da hätte ich dann aber wieder das Problem mit der Namensgleichheit Namespace <-> Klasse.

Ich hoffe, die Problematik gut genug erläutert zu haben.

Ich möchte Euch wirklich nicht nerven, aber ich denke, ich muss gerade so ein grundlegendes Thema verstehen, ansonsten verrenne ich mich irgendwann ganz dolle.

Ich bin ehrlich gesagt gerade ziemlich frustriert.

Wie kann ich das denn jetzt am besten lösen? 🙁

Ich meine, so ein Namespace, der wächst ja. Und in einem Jahr weiß ich vielleicht gar nicht mehr, dass ich schon in irgendeinem anderen Projekt (welches sich im gleichen Namespace befindet) schon einmal eine Enumeration mit dem gleichen Namen habe.

Bei Klassen, da denkt man ja vielleicht noch dran, aber bei Enums...

assemblynamen namespace.

<firmenname>.<assembyname>.....

Wenn ein Enum ganz speziell für nur eine Klasse gebraucht wird, benenne ich das Enum meist so, das man gleich erkennt, das es nur was mit der einen Klasse zu tun hat.
In deinem Falle wäre es also TestButton1Sichtbarkeit und TestButton2Sichtbarkeit.

Das wäre IMHO eine elegante Lösung. Weniger elegant, was aber dennoch funktioniert ist, das du das enum in die Klasse packst. Also

public class TestButton1
{
  public enum Sichtbarkeit
  {
    // Bla
  }
}

Dies ist allerdings wirklich nicht zu empfehlen, das man sich irgendwann verrennt und es sich auch Blöde tippen lässt

TestButton1 test = new TestButton1();
test.Sichtbarkeit = TestButton1.Sichtbarkeit.NichtSichtbar;

Und blöde Tippen lassen ist für mich ein sehr schwerwiegendes Argument, denn das Programmieren an sich, muss schnell von der Hand gehen. Da muss man halt nur tippen. Sowas hält ein nur auf und verringert deutlich die lesbarkeit des Textes.

Deswegen empfehle ich dir Variante1: Benenne spezielle Enums so um, das sich gleich erkennen lässt du welcher Klasse diese gehören.

assemblynamen namespace.

<firmenname>.<assembyname>.....

Tut mir leid (für mich), aber ich verstehe nicht, was Du damit meinst 🙁

@Khalid
Das wäre eine Möglichkeit.

Ich erzeuge eine Anwendung, die die beiden oben genannten Steuerelemente TestButton1 und TestButton2 einsetzt.
Also füge ich den Verweisen die beiden DLLs MeinName.GUI.Controls.TestButton1.dll und MeinName.GUI.Controls.TestButton2 hinzu.

dll == assemblie
assemblie.Contains(assembliename)

namspace:
<firmenname>.<assembliename>.<logische gruppierung>......

Also,

meine Assembly nenne ich TestButton1. Da es sich um ein Steuerelement handelt, wird daraus dann TestButton1.dll.

Nach Deiner Beschreibung oben müsste dann der Namespace folgendermaßen heißen:
MeinName.TestButton1.Controls
<firmenname> => MeinName
<assemblyname> => TestButton1
<logische Gruppierung> => Controls

Da habe ich dann aber wieder das ursprüngliche Problem der Gleichheit von Namespace <-> Klasse, d.h. ich könnte die Klasse TestButton1 wieder ausschließlich über ihren vollqualifizierten Namen ansprechen 🙁

Tut mir leid, aber irgendwie habe ich vollkommen den Faden verloren.

Und noch eine Frage in diesem Zusammenhang:
Gibt es für mich irgendeine Möglichkeit, solche Redundanzen innerhalb der Namespaces festzustellen?
Denn erst wenn in einer anderen Anwendung, die auf meine beiden Assemblies verweist, versucht wird, auf diese Enumeration zuzugreifen meckert der Compiler, dass die Enum in zwei Assemblies vorhanden ist.

D.h. gebe ich die beiden Assemblies weiter, bekommt der User, der sie bei sich einbaut, den Fehler, der mir vorher gar nicht aufgefallen ist, da ich die beiden Steuerelemente nicht gleichzeitig in einer Anwendung benutzt habe.

was spricht eigendlich dagegen testbutton1 und testbutton2 in eine assemblie zu tun?

Dagegen spricht zum einen die Tatsache, dass ich alles, was ich mache separat in eigenen Projekten verwalten möchte.

Zum anderen spricht dagegen, dass, wenn man das Ganze kommerziell aufzieht, und die Controls (einzeln) anbieten möchte, natürlich nicht beide in einer Assembly vertrieben werden können.

Verrückte Welt.

Aus irgendeinem mir nicht ersichtlichen Grund, ist es nun doch möglich, den Klassennamen in den Namespace zu integrieren, und trotzdem ohne den vollqualifizierten Namen auf die Klasse zuzugreifen, was ja gestern nicht möglich, und deshalb der Anlass zu diesem Thread war.

In Abstimmung mit den anderen Vorschlägen, heißt mein Namespace, der das Steuerelement / die Klasse TestButton1 beinhaltet, nun so:

MeinName.GUI.Controls.TestButton1

Die Assembly entsprechend dazu dann

MeinName.GUI.Controls.TestButton1.dll

Auch wenn der FXCop anmeckert, dass der Klassenname kein Teil des Namespace sein sollte, ist das aus meiner Sicht doch die angenehmste Methode, alles in separaten Projekten zu verwalten und zu veröffentlichen, und dennoch Redundanzen sicher zu vermeiden.

Sollte irgendjemand Einwände gegen dieses Vorgehen haben, die meine Arbeit zukünftig lahmlegen würde oder durch die ich große Probleme bekommen könnte, dann höre ich sie mir natrülich gerne an 😉

Hallo s-sharp,

Sollte irgendjemand Einwände gegen dieses Vorgehen haben, die meine Arbeit zukünftig lahmlegen würde oder durch die ich große Probleme bekommen könnte, dann höre ich sie mir natrülich gerne an

Wir haben ja schon oben ausführlich begründet, warum du das auf keinen Fall machen solltest. Es ist irgendwie doch eine Vergewaltigung, wenn du Namesspaces wie Klassen nennst. Dafür sind sie einfach nicht da. Ich denke auch nicht, dass du damit auf Dauer glücklich wirst.

herbivore

Ach, ist das alles doof 🙁

Ich habe ja nicht je Klasse einen Namespace.
Ein Steuerelement kann ja auch aus mehreren Klassen bestehen; die stehen dann alle in dem Namespace; oder aber in Subnamespaces.
Dann hätte diese eine Assembly halt mehrere Namespaces.

Namespace <-> Assembly ist eine 1:n Beziehung; eine Assembly kann mehrere Namespaces beinhalten. Aber ich möchte vermeiden, dass ein Namespace über mehrere Assemblies verteilt ist, um Redundanzen zu vermeiden.

Und das ist doch beim .Net-Framework genauso. Je Namespace eine Assembly.

Wenn ich ein neues Projekt erstelle, dann bekommt der Namespace ja standardmässig auch den Namen des Projektes zugewiesen.
Innerhalb dieses Projektes kann ich dann weitere Namespaces erstellen.
Die Assembly besteht dann ggf. also aus mehreren Assemblies; also wieder eine 1:n Beziehung.

Und wenn ich dann ein weiteres Projekt erstelle, dann bekommt dieses ja wieder einen anderen Namespace.

Und solange ich keine funktionalen Einschränkungen dadurch habe, kann es ja nicht so tragisch sein.

Das eigentliche Problem ist doch, dass ich bei diesen Namespace-Geschichten nicht je Projekt aufpassen muss, keine Redundanzen zu produzieren, sondern global für jede Zeile Code, die ich produziere - sofern ich allgemeine Namespaces benutze.

Und das ist doch beim .Net-Framework genauso. Je Namespace eine Assembly.

nein ist es nicht.

Und das ist doch beim .Net-Framework genauso. Je Namespace eine Assembly.
nein ist es nicht.

Nicht?

Namespace = System / Assembly = System.dll
Namespace = System.AddIn / Assembly = System.AddIn.dll
Namespace = System.AddIn.Contract / Assembly = System.AddIn.Contract.dll

.....

Hmm, da habe ich tatsächlich einen gefunden.

Der Namespace System.Drawing.Design; der ist einmal in_ System.Drawing.dll_ und einmal in System.Drawing.Design.dll vorhanden 🙁

Okay, Du hast recht.

****

Kann doch nicht angehen, dass man sich eine Woche damit aufhält, wie man seine Namensräume benennt. Und dann denkt man, endlich etwas gefunden zu haben, und schon ist es wieder nicht richtig - so ein Käse 🙁

Ist mir jetzt ehrlich gesagt aber auch egal. Ich ziehe das jetzt so durch, und gut is.

Hallo s-sharp,

ich verstehe ehrlich gesagt dein Problem nicht so ganz.

Statt MeinName.GUI.Controls.TestButton1 nennst du deinen Namespace MeinName.GUI.Controls oder sogar MeinName.GUIControls und damit ist es doch gut.

Das eigentliche Problem ist doch, dass ich bei diesen Namespace-Geschichten nicht je Projekt aufpassen muss, keine Redundanzen zu produzieren, sondern global für jede Zeile Code, die ich produziere - sofern ich allgemeine Namespaces benutze.

Doch nicht für jede Zeile Code, sondern nur für bzw. bei jeder Klasse (oder genauer gesagt für bzw. bei jedem Typ). Das ist doch überschaubar.

Ein Beispiel: Wenn du jeden Namespace MeinName.GUIControls.MeineKlasse nennst, dann hast du das Problem der Redundanzen einfach eine Ebene höher verlagert. Statt aufzupassen, dass es in MeinName.GUIControls keine zwei gleichen Klassen gibt, musst du jetzt aufpassen, dass es nicht zwei gleiche Namespaces gibt.

herbivore

namespace system z.b.:

mscorlib.dll
system.dll
system.xml.dll
system.web.dll
system.drawing.dll
usw....

@herbivore

Du hast ja recht. Und wenn der Compiler meckern würde, dass dieser oder jener Typ schon in diesem oder jenem Namespace vorhanden ist, dann wäre das ja auch alles halb so wild.
Dann würde ich sofort beim Programmieren darauf aufmerksam gemacht, und könnte etwas ändern.

Das tut er aber nicht. Er meckert erst, wenn zwei Assemblies, die einen gleichen Namespace haben, und diese widerum einen gleichen Typen haben aufeinandertreffen.
Das würde ich unter Umständen gar nicht mitbekommen, sondern vielleicht erst der Endanwender, wenn er die beiden besagten Steuerelemente gleichzeitig in einer Anwendung einsetzen möchte.
Denn dann wäre es nicht möglich, auf den Typen in der zweiten Assembly zuzugreifen, da dieser durch den aus der ersten Assembly überdeckt wird.

Bei wenigen Projekten mag man ja vielleicht noch den Überblick behalten. Da weiß man noch, dass man diesen oder jenen Typen in diesem oder jenem Projekt implementiert hat.
Wenn das, was man so fabriziert aber immer mehr und mehr wird, dann glaube ich kaum, dass sich jeder noch daran erinnern kann, ob er nicht vielleicht in Steuerelement X, was er vor drei Jahren mal programmiert hat, nicht zufällig auch die Enumeration Y verwendet hat.
Denn genau dann hat man nämlich oben genanntes Problem.

Im Gegensatz dazu weiß ich schon, dass ich vor drei Jahren mal das Steuerelement X programmiert habe, und somit den Namespace MeinName.GUI.Controls.X nicht mehr benutzen darf.
Das würde sogar dadurch ersichtlich, dass ich dann zwei Assemblies mit dem gleichen Namen hätte, da Namespacename = Assemblyname.

Der Einwand von Khalid, sämtlichen Typen den Namen des 'Haupttypen' voranzustellen, kann, was die Lesbarkeit des Codes angeht, aber auch nicht das Wahre sein - auch wenn es helfen würde.

Sind meine Bedenken denn so absurd, dass sich diesbezüglich noch niemand Gedanken gemacht hat, bzw. dieses nicht kundtut?

@JAck30lena
Das ist klar; das meinte ich so aber nicht.

'System' sehe ich als einen alleinstehenden Namespace an (auch wenn es terminologistisch nicht korrekt ist; es ist aber analog zu meiner Situation).

Und der Namespace 'System' ist in der System.dll.

Der Namespace System.Xml in System.Xml.dll - so meinte ich das.

(siehe mein Beispiel mit System.Drawing.Design)

Hallo s-sharp,

Sind meine Bedenken denn so absurd, dass sich diesbezüglich noch niemand Gedanken gemacht hat [...]?

Wenn du so fragst ... 🙂

Was das Gedanken machen angeht: An den Antworten siehst du doch, dass wir uns alle Gedanken darum gemacht haben. Und alle sagen übereinstimmend, dass du Klassennamen nicht als Namespacenamen verwenden sollst. Es wäre doch absurd, wenn wir uns alle (Microsoft und FxCop eingeschlossen) an dieser Stelle irren sollten.

Das tut er aber nicht. Er meckert erst, wenn zwei Assemblies, die einen gleichen Namespace haben, und diese widerum einen gleichen Typen haben aufeinandertreffen.

Das ist doch nur eine Frage deines Build-Prozesses. Bevor du eine neue, einzelne Assembly auslieferst, übersetzt du den gesamten Code des entsprechenden Namespaces testweise zusammen in eine einzige Assembly. Gibt es keine Konflikte, kannst du die einzelne Assembly ausliefern. Gibt es Konflikte, benennst du die beteiligten Typnamen um, übersetzt die einzelne Assembly neu und bist fertig.

Jedenfalls sind deine Bedenken kein Grund schlechte Namespace-Namen zu verwenden. Du "missbrauchst" dann die Namespaces, um eine Schwäche deines Build-Prozesses zu stopfen.

herbivore

Der Einwand von Khalid, sämtlichen Typen den Namen des 'Haupttypen' voranzustellen, kann, was die Lesbarkeit des Codes angeht, aber auch nicht das Wahre sein - auch wenn es helfen würde.

Eine Codedatei ist nicht gleich ein Namespace.

Z.B. die Ordnerstruktur für Controls

- Ordner: xxx.Windows.Forms
 - Klasse1.cs
 - Klasse2.cs
   - Ordner Designs
     - Klasse1.Designer.cs
   - Ordner Interfaces
     - IInterface1.cs
     - IInterface2.cs
   - Ordner Common
     - Common1.cs

usw.

Aber alle Codedateien liegen in nur einem Namespace. Ist für mich ziemlich übersichtlich.

Hallo s-sharp,

Sind meine Bedenken denn so absurd, dass sich diesbezüglich noch niemand Gedanken gemacht hat [...]?
Wenn du so fragst ... 🙂

😉

Das tut er aber nicht. Er meckert erst, wenn zwei Assemblies, die einen gleichen Namespace haben, und diese widerum einen gleichen Typen haben aufeinandertreffen.
Das ist doch nur eine Frage deines Build-Prozesses. Bevor du eine neue, einzelne Assembly auslieferst, übersetzt du den gesamten Code des entsprechenden Namespaces testweise zusammen in eine einzige Assembly. Gibt es keine Konflikte, kannst du die einzelne Assembly ausliefern. Gibt es Konflikte, benennst du die beteiligten Typnamen um, übersetzt die einzelne Assembly neu und bist fertig.

Okay, das wäre eine Möglichkeit. Allerdings eine, die mit nicht wenig Arbeit verbunden ist.
Da ich nicht alles in einen Ordner stopfe, sondern meine Projekte ordentlich strukturiert auf der Festplatte ablege, müsste ich mir dann erst aus den einzelnen Projekten die Assemblies mit dem entsprechenden Namespace heraussuchen.
Darüber muss ich mal genauer nachdenken, ob sich das praktikabel umsetzen lässt.
Von Grund auf ausschließen würde ich das jetzt nicht 🙂

Jedenfalls sind deine Bedenken kein Grund schlechte Namespace-Namen zu verwenden. Du "missbrauchst" dann die Namespaces, um eine Schwäche deines Build-Prozesses zu stopfen.

Also als 'schlecht' würde ich das nicht bezeichnen. Es entspricht, zugegebenermaßen, nicht dem Standard, dem sicherlich 98% aller .NET-Entwickler folgen. Aber es ist nicht 'schlecht', denn ich habe keinerlei funktionelle Einschränkungen dadurch.

Es ist sicherlich auch eine Philosophie. Und wenn Microsoft in den Anfängen propagiert hätte 'Leute benennt Eure Namensräume nach den Klassen, die sie beinhalten', dann würde sich wohl auch jeder daran halten 😉

Denn vom Deployment her macht es prinzipiell gar keinen Unterschied.

Dennoch werde ich mal über Deinen Vorschlag nachdenken 😉

@Khalid
Da haben wir aneinander vorbei geredet 😉
Es ging mit um das Beispiel mit TestButton1Sichtbarkeit und TestButton2Sichtbarkeit.

Hallo s-sharp,

Da ich nicht alles in einen Ordner stopfe, sondern meine Projekte ordentlich strukturiert auf der Festplatte ablege, müsste ich mir dann erst aus den einzelnen Projekten die Assemblies mit dem entsprechenden Namespace heraussuchen.

gerade wenn die Projekte ordentlich strukturiert sind, solltest du da nicht lange suchen müssen.

dann würde sich wohl auch jeder daran halten

Darauf würde ich nicht Wetten. Nichts ist so schwer durchzusetzen, wie Konventionen. Es gibt immer Abweichler. Das sieht man gut hier an dem Code, der im Forum gepostet wird. Um so bezeichnender ist es, dass es am Punkt "keine Klassennamen als Namespacesnamen" keine Abweichler gibt.

denn ich habe keinerlei funktionelle Einschränkungen dadurch.

Nö, nur die Benutzer deiner Klassen, die sich an den nötigen Usings die Finger wund schreiben. 🙂

herbivore

Da haben wir aneinander vorbei geredet
Es ging mit um das Beispiel mit TestButton1Sichtbarkeit und TestButton2Sichtbarkeit.

Ja, da haben wir wohl aneinander vorbeigeredet 😉

Da ich nicht alles in einen Ordner stopfe, sondern meine Projekte ordentlich strukturiert auf der Festplatte ablege, müsste ich mir dann erst aus den einzelnen Projekten die Assemblies mit dem entsprechenden Namespace heraussuchen.
gerade wenn die Projekte ordentlich strukturiert sind, solltest du da nicht lange suchen müssen.

Da hast Du recht, das müsste ich auch nicht 😉
Ich habe es gerade mal ausprobiert.

Zwei DLLs mit unterschiedlichem Namen.
Beide haben den gleichen Namensraum TestNamespace
Jeder der beiden Namensräume hat die Klasse TestKlasse
Ich binde die beiden DLLs als Verweis in ein Projekt ein und kompiliere es => funktioniert ohne Probleme.
Erst dann, wenn ich eine der beiden Klassen direkt ansprechen will, meckert der Compiler.
Damit wäre das Verfahren leider nicht praktikabel - schade 🙁

dann würde sich wohl auch jeder daran halten
Darauf würde ich nicht Wetten. Nichts ist so schwer durchzusetzen, wie Konventionen. Es gibt immer Abweichler. Das sieht man gut hier an dem Code, der im Forum gepostet wird. Um so bezeichnender ist es, dass es am Punkt "keine Klassennamen als Namespacesnamen" keine Abweichler gibt.

Nun ja, dass Namensräume nicht die Namen ihrer Klassen enthalten sollen ist ja auch eine Konvention; und diese hat sich ja unbestritten durchgesetzt 😉
Woher weißt Du denn, dass es bzgl. der Bennenung von Namensräumen keine Abweichler gibt?
Die paar Leute, die ihren Code hier im Forum posten, sind im Vergleich zur gesamten .NET-Gemeinde kaum repräsentativ 😉
Auch wenn man schon sich viele Fremdprojekte angeschaut hat - ich glaube, eine Aussage zu treffen, die auf die Mehrheit aller .NET-Entwickler zutreffen ist, ist nicht einfach.

denn ich habe keinerlei funktionelle Einschränkungen dadurch.
Nö, nur die Benutzer deiner Klassen, die sich an den nötigen Usings die Finger wund schreiben. 🙂

Stimmt 😠
Mich persönlich würde es nicht stören, da ich es aus Delphi gewohnt bin, zig Units in der Uses-Klausel unterzubringen 😉

Und der Namespace 'System' ist in der System.dll.

das siehst du vollkomen falsch.

der namespace ist in vielen dll´s wie ich bereits schrieb und jede dll bringt ein paar klassen dazu.

Hallo s-sharp,

Damit wäre das Verfahren leider nicht praktikabel

das Verfahren, dass ich oben geschrieben habe, funktioniert anders als du es probiert hast und es funktioniert.

Woher weißt Du denn, dass es bzgl. der Bennenung von Namensräumen keine Abweichler gibt?

Weil ich den Thread gelesen habe. 🙂 Mehr habe ich nicht gemeint. Vielleicht habe ich auch was überlesen. Aber es hat dir doch hier jeder abgeraten, oder?

herbivore

Und der Namespace 'System' ist in der System.dll.
das siehst du vollkomen falsch.

der namespace ist in vielen dll´s wie ich bereits schrieb und jede dll bringt ein paar klassen dazu.

So, bin jetzt den kompletten Objektbrowser durchgegangen.
Du hast recht; der Namespace befindet sich in mehr als einer DLL. Aber 'viele' sind das auch nicht; denn es sind genau drei, in denen sich der Namespace 'System' (nur 'System', nicht 'System.xml' oder 'System.irgendwas') befindet:

System.dll
System.Core.dll
System.ServiceModel.Web.dll

Damit wäre das Verfahren leider nicht praktikabel

das Verfahren, dass ich oben geschrieben habe, funktioniert anders als du es probiert hast und es funktioniert.

Hmm, Du schriebst, ich solle den gesamten Code des Namespaces in eine Assembly linken.
Da sich besagter Namespace in mehreren Assemblies befindet, muss ich doch einfach - nee, das ist quatsch.
Aber wie kann ich das denn einfach machen?
Muss ich mir dann alles, was zu einem Namespace gehört, per Copy&Paste zusammen in eine Quellcodedatei kopieren? 8o
Das kann bei x-Ursprungsquellcodedateien aber ganz schön mühselig sein.

Oder gibt es eine Vorgehensweise, die einfacher ist?

Hallo s-sharp,

wie es bei VS geht weißt ich nicht. Aber vermutlich wird es da auch irgendwie gehen.

Ich verwende nmake und da kann ich natürlich beliebige makefiles benutzen, je nach Bedarf. Sprich die Quelldateien stehen (ganz ohne Copy&Paste) einfach hübsch sortiert auf der Platte und wie sie gerade (zusammen-)compiliert werden bestimmt das eingesetzte makefile.

herbivore

Ach herrjeminechen 😠

Nun gut, dann werde ich mich bzgl. MakeFiles wohl mal schlau machen müssen.

(Nein, ich bin nicht doof. Nur erstellt bei uns in der Firma jemand anderes die Builds. Und für private Zwecke brauch(t)e ich keine MakeFiles 😉 )

Danke für den Tipp!

ah... es ist irgendwie mühsam wissen an dich weiterzugeben.
schau dir das doch im reflector an. denkst du ich versuche dich anzulügen?

fogendes:
namespaces sind logische einheiten.
assemblies sind physikalische einheiten.

du kannst z.b. pro assemblei je ein conrolsatz haben mit allem was dazugehört.
alle controls können auch im selben namespace sein. das hat dann den vorteil, das der anwender nicht 123123123123 usings in seinem code haben muss.

also:
namespace = logische gruppierung
assemblie = physikalische gruppierung.

aus diesem grundsatz kannst du auch schlussfolgern, das ein namespace keinen klassennamen tragen sollte, da eine klasse keine logische gruppierung ist, sondern eine konkrete (ich nenne es mal) "bauanleitung".

Aber 'viele' sind das auch nicht; denn es sind genau drei

Sind ein bisschen mehr. Im Objektbrowser sieht man nur nicht alle.

z.B.
System.Xml.dll
System.Web.dll
System.Drawing.dll
nicht zu vergessen den Kern von .NET die mscorlib.dll
und noch zig andere.

schau dir das doch im reflector an. denkst du ich versuche dich anzulügen?

In welcher Hinsicht? Damit, dass sich der Namespace 'System' nicht in 'vielen' Assemblies widerfindet, sondern nur in dreien?
Was kann mir der Reflector mehr sagen, als der IDE-interne Objektbrowser?

Nein, Du willst mich ganz bestimmt nicht anlügen; ich glaube, dass wir an diesem Punkt ganz kräftig aneinander vorbei reden.

Ich habe es gerade nochmal überprüft, und dabei ist mir aufgefallen, dass sich der Namespace 'System' in einer vierten Assembly befindet; an 'mscorlib' hätte ich nicht gedacht.

Ich habe Dir mal einen Screenshot angehängt, vielleicht wird dann klar, was ich meine.
Dort ist ganz klar ersichtlich, dass sich der Namespace 'System' in vier Assemblies befindet.

Und daran gibt es doch wohl nichts zu rütteln. Oder willst Du sagen, dass der Objektbrowser uns anlügt? 😉

(Der Reflector sagt übrigens das Gleiche.)

fogendes:
namespaces sind logische einheiten.
assemblies sind physikalische einheiten.

Das weiß ich.

du kannst z.b. pro assemblei je ein conrolsatz haben mit allem was dazugehört.

Auch damit erzählst Du mir nichts Neues.

alle controls können auch im selben namespace sein. das hat dann den vorteil, das der anwender nicht 123123123123 usings in seinem code haben muss.

Ich denke, dass ich mich dazu bereits geäußert habe. (Stichworte: Übersichtlichkeit / 10 Jahre später, u.U. redundante Typnamen usw...)

aus diesem grundsatz kannst du auch schlussfolgern, das ein namespace keinen klassennamen tragen sollte, da eine klasse keine logische gruppierung ist, sondern eine konkrete (ich nenne es mal) "bauanleitung".

Nö, eine klasse würde ich eher als logische Grundlage eines zu realisierenden physikalischen Objektes ansehen.

Aber ist auch alles egal jetzt.
Ich mache das jetzt so, wie ich am besten klarkomme und fertig.

Habe den FXCop zum Spass mal über einige Assemblies rattern lassen, die ich hier im Forum unter 'Projekte' gefunden habe.
Bei teilweise über 200 Meldungen liege ich mit meinen vier Meldungen (ja, auch 'der Klassenname soll nicht dem Namespacenamen entsprechen') ja noch recht gut im Rennen 😁

Edit:@Khalid
Genau das ist der Punkt, an dem ich denke, dass wir aneinander vorbei reden (also JAck30lena und ich)
In der System.xml.dll sehe ich keinen Namespace System, wie der untere Teil des Screenshots zeigt.

Aber wenn Du sagst, dass der Objektbrowser nicht alles anzeigt und da unter den anderen Namespaces vielleicht doch noch der 'System' versteckt ist... dann liege ich wohl doch falsch und kann mich auf die Werkzeuge, die MS liefert, nicht verlassen (und auf den Reflector auch nicht).

Hmm, ist 1a ein System namespace drin.

Wie gesagt, der Objektbrowser erzählt nicht alles

8o

Entschuldigung an JAck30lena und auch an Dich, Khalid.
Besonders aber an JAck30lena; dem habe ich es wohl nicht so leicht gemacht, mit meinem 'Ich habe aber recht, weil der Objektbrowser mir das sagt'-Gepoche - 'tschuldigung 🙁

Frei nach herbivore: "Ein Screenshot sagt mehr als 1000 Worte" X(

Naja, da hab ich wohl derbe ins Klo gegriffen. Aber woher soll ich auch wissen, dass mir das Arbeitswerkzeug, das mir für viel Geld an die Hand gegeben wird, die Hälfte verschweigt?!

Traurig 🙁