Ok, der Titel klingt vielleicht etwas vage, aber ich kann mir hier wirklich nichts einfallen lassen.
Ich war vor kurzem in der Position, wo ich eine Point -Klasse brauchte, einfach mit zwei Eigenschaften, X und Y und einer ctor Point(int x, int y) . Nichts Außergewöhnliches. Nun, dieses Ding existiert bereits in .NET, aber das war in einer Bibliothek, die bestimmte Objekte auf einer Karte behandelte und System.Drawing hineinzog, fühlte sich einfach irgendwie ... falsch an. Auch wenn System.Drawing.Point genau zu dem passt, was ich wirklich benötigt habe, habe ich nun diese Struktur selbst in diesem Projekt erstellt.
Nun frage ich mich, ob das richtig oder vernünftig war. System.Drawing.Point wäre auch mit einem Verweis auf diese Assembly gekommen, wenn ich mich richtig erinnere. Und etwas in System.Drawing in einen völlig nicht zeichnungsbezogenen Kontext zu setzen, war irgendwie komisch.
Gedanken? Was wäre, wenn es keinen Hinweis auf eine andere Baugruppe hätte?
Der Kontext des Namespace ist grundlegend für die Annäherung an die genaue Funktion einer Klasse; Eine Connection -Klasse wird ein ganz anderes Biest von einem Namespace zum nächsten sein. Ist eine Web.Cache -Klasse für das Caching in anderen Anwendungen geeignet oder hat sie eine grundlegende Abhängigkeit von der Web-Infrastruktur?
MSDN beschreibt System.Drawing.Point structure wie folgt:
"Repräsentiert ein geordnetes Paar ganzzahliger x- und y-Koordinaten, die einen Punkt in einer zweidimensionalen Ebene definieren."
Mit einer solchen allgemeinen Beschreibung könnte argumentiert werden, dass diese Struktur nur beiläufig mit dem Zeichnen in Zusammenhang steht und wirklich in einen grundlegenderen Namensraum gehört.
Da es jedoch in System.Drawing existiert, bedeutet dies, dass es einen Punkt innerhalb eines zweidimensionalen Zeichenraums darstellt. Daher ist die Verwendung der Klasse für andere Zwecke als das Zeichnen ein Fehlgebrauch; Es kann für Ihre Bedürfnisse funktionieren, aber es wird nicht für seinen ursprünglichen Zweck verwendet.
Ich stimme den anderen Antworten bisher nicht zu und sage, dass es wirklich zählt. Der Point -Beitrag ist ein einfacher, aber im Allgemeinen kann die Verwendung einer Klasse in einem Kontext, für den sie nicht entworfen wurde, unerwünschte Auswirkungen haben.
Eine Klasse kann nur für einen bestimmten Anwendungsfall implementiert worden sein, z. keine Unterstützung für Threadsicherheit, die die Verwendung innerhalb eines Frameworks erfordert oder Funktionen freigibt, die in Ihrem Code unerwünscht sind.
Dies kann insbesondere zu Problemen führen, wenn eine neuere Version der Assembly bereitgestellt wird, die nicht mehr mit der Art der Verwendung kompatibel ist, oder die neuere Version zusätzliche Member und Abhängigkeiten enthält, in denen Sie nicht enthalten sein sollen Ihr Code.
Ich würde nicht sagen, dass das, was Sie getan haben, falsch war, aber ein Namespace ist eigentlich nur ein Container für Deklarationen, in denen jeder Name eindeutig ist. Der Namespace-Name bietet einen Kontext, der Ihnen hilft, die richtige Funktion für Ihre Bedürfnisse zu finden Halte dich nicht an den Kontext, der deiner Nutzung nicht ganz entspricht, wenn das Objekt ideal ist, dann ist es ideal. Abgesehen von der using-Anweisung werden Sie wahrscheinlich nie wieder aktiv auf den Namespace verweisen.
Wenn Ihr Zweck für den Punkt in keiner Weise bezogen wurde, denke ich, dass Sie das Richtige getan haben. Wenn Sie einen System.Drawing.Point-Code verwenden, der überhaupt nichts mit der Zeichnung zu tun hat, kann das dazu führen, dass die Leute denken, dass sie für einige Zeichnungsfunktionen verwendet wird.
Ich war in letzter Zeit in einer ähnlichen Situation. Ich brauche die Point-Klasse nicht, aber ich werde das als Beispiel verwenden.
Ich habe meine eigene Point-Klasse erstellt, weil System.Drawing.Point ints verwendet, wenn ich doubles brauchte. Später stellte ich fest, dass es eine gute Idee war, auch wenn ich nur Ints benötigte, weil ich dann die Klasse nach Bedarf erweitern und Methoden, Schnittstellen und Attribute hinzufügen konnte. Dagegen hätte ich das System nicht verwenden können .Drawing.Point.
Es gibt das Prinzip, dass Sie Wissen in Ihren Programmen nicht duplizieren sollten, aber in einigen Fällen wie diesem kann es nicht vermieden werden.
Sie können folgendermaßen auf eine andere Assembly verweisen:
%Vor%Wenn Sie kein "Gepäck" importieren (wie Dinge initialisieren müssen, die Sie nicht verwenden), also ist es genau das, was Sie brauchen, würde ich den bestehenden Code wählen. Es macht keinen Sinn, bestehenden Code neu zu erstellen. Es besteht auch die Möglichkeit, dass Sie später Funktionen entdecken, die Funktionen ausführen, die Sie benötigen, und diese bestimmte Klasse erwarten.
Dennoch kann ich mich identifizieren, wenn ich mich merkwürdig fühle, wenn ich ein "fremdes" Objekt in deinem Code habe. Eine Möglichkeit, dies zu umgehen, wäre, es mit Ihrem eigenen Punkt zu untergliedern. Das wird etwas komisch aussehen, wenn Sie nichts in Ihrer Unterklasse ändern, aber das ist nur in der Quelle dieser Klasse sichtbar, und wo Sie sie verwenden, wird sie konsistent benannt. Außerdem wird es wirklich schlau aussehen, sobald Sie feststellen, dass Sie Ihrem benutzerdefinierten Point Funktionalität hinzufügen.
Ich würde mich sehr wenig darum kümmern, etwas aus dem Namespace zu holen, da es funktional und konzeptionell (wie es in den Dokumenten beschrieben wird) dem Ziel entspricht.
Ich könnte allerdings zögern, eine neue Versammlung einzubringen. In diesem Fall ist die Tatsache, dass Point so schnell ist, dass man sich die Mühe macht, dies weniger zu tun, als das Hinzufügen einer anderen Abhängigkeit zu der Versammlung, die ich geschrieben habe.
Sonst, solange ich es nicht als Schlüssel benutzte (der GetHashCode impl. in Punkt ist nicht groß in der Art wie er kollidiert für zB alle von {0,1}, {1,0}, { 2,3} und {3,2} wenn Sie viele niedrigwertige oder rechteckig verteilte Punkte haben, würde ich es verwenden.
Tags und Links .net c# namespaces