Platzieren von benutzerdefiniertem Code in einem Systemnamespace

Question

Gibt es Best Practices, die besagt, dass benutzerdefinierter Statuscode nicht in einem System-Namespace platziert werden sollte? Sollte System und seine Kinder für Microsoft-Code reserviert sein?

Ich frage, weil ich eine Klassenbibliothek schreibe, die über viele Projekte hinweg verwendet wird, und ich möchte die Dinge konsistent halten, indem Sie es in System.InteropServices platzieren (da es P/Invoke behandelt).

Answer 1

Es ist keine gute Idee, weil es einen der Hauptvorteile von Namespaces besiegt: Namenskonflikte verhindern. Was, wenn eine neuere Version des Frameworks einen gleichnamigen Typ in diesem Namespace einführte?

Dies ist besonders schlecht für System Namensräume, da sie in vielen anderen Teilen des Codes mit using Richtlinien eingeführt und Typen individuellen Einführung in dem Namespaces verpestet die Namensgebung Rahmen anderer Quelldateien mit unerwarteten Bezeichner.

Um Ihre benutzerdefinierten Interop-Typen zu kategorisieren, können Sie einen neuen Namespace wie MyProduct.InteropServices erstellen.

Answer 2

Wenn Sie eine neue Klasse in System.InteropServices platzieren, wird jede Datei, die eine using System.InteropServices;-Klausel hat, gezwungen, Ihre Klasse im Geltungsbereich zu haben, was den Programmierer verwirren kann. Da sich der Programmierer dagegen nicht wehren kann, würde ich diese schlechte Praxis in Betracht ziehen.

Answer 3

Ich stimme nicht mit allen überein.

Ich denke, dass in einer begrenzten Teilmenge von Fällen (meist mit Erweiterungsmethoden) es durchaus sinnvoll ist, Code in einem Systemnamespace zu platzieren.

Hier ist meine Seite des Arguments aus einem E-Mail-Thread wir Erweiterungsmethoden im System-Namespace über an EPS debattieren hatten:

---

Ok, hier so meine Seite des Arguments:

1. Ich mag es wirklich, Code zu minimieren. Das schließt Usings ein.

2. Ja, ReSharper greift auf Erweiterungsmethoden zu und fügt den Gebrauch für Sie hinzu, aber einige Leute haben ReSharper nicht, und außerdem bevorzuge ich Coderush, das bis jetzt (soweit ich weiß) keine Erweiterung auswählt Namespaces.

3. Es gibt mindestens zwei verschiedene Arten von Erweiterungsmethoden; Diese sind Hilfsmethoden für unsere Anwendung - einschließlich domänen- und anwendungsspezifischer Helfer und solche, die Funktionen und Syntax kapseln, von denen wir glauben, dass sie mit der Sprache hätte beginnen sollen.

Ein gutes Beispiel für letzteres ist die Fähigkeit, "a {0} {1}".Format("b", "c") oder someListOfStrings.Join(", ") eher zu tun, als String.Join(someStringList.ToArray(), ", ") zu tun. Andere umstrittenere Beispiele sind IEnumerable<T>.ForEach und die IsNull() Erweiterung, die die plumpe object.ReferenceEquals(null, someVar) Syntax ersetzen.

Mein Argument ist, dass es allen Grund gibt, diese letztere Klassifizierung - Ihr Team ist weitgehend einverstanden in der Sprache, aber nicht - in den entsprechenden Namespace (System, System.IO, System.Linq usw.) zu platzieren.).Wir möchten, dass diese Funktionen überall verfügbar sind, so wie wir es bevorzugen, dass die Schlüsselwörter foreach und yield immer sichtbar sind. Wenn es jedoch anwendungsspezifisch ist, sollte es in einem eigenen Namensraum liegen. In 90% der Fälle sollten anwendungsspezifische Helfererweiterungen wahrscheinlich keine Erweiterungen sein und nicht einmal statisch sein. Ich schließe diese Anweisung aus, indem ich Erweiterungsmethoden verwende, um Aliase für Funktionsnamen bereitzustellen.

Sie können natürlich Probleme bekommen, wenn Sie in Assemblys anrufen, die systemweite Erweiterungen enthalten. Angenommen, ich habe auf die Assembly verwiesen, die meine void-Methode IEnumerable<T>.ForEach enthält, und wollte mein eigenes Ruby-ähnliches R IEnumerable<T, R>.ForEach erstellen (was eigentlich nur ein Select ist, aber vergiss das nicht). Das wäre ein Problem! Was ich tun möchte, um das Problem zu verringern, besteht darin, meine Erweiterungsklassen als intern zu definieren, sodass sie nur für mein Projekt verwendet werden können. Dies löst das Problem gut.