Verdienste von Namespaces / Paketen


14

Einige Programmiersprachen (z. B. Java und C ++) verfügen über Sprachfunktionen, die als "Pakete" oder "Namespaces" bezeichnet werden. Wie nützlich ist es wirklich, Namespaces zu haben? Es ist möglich, Funktionen und Klassen als zu einer bestimmten Bibliothek gehörig zu kennzeichnen, ohne eine solche Sprachfunktion zu verwenden, wie dies beispielsweise in SDL der Fall ist SDL_BlitSurface(). Sind Namespaces nicht hilfreich genug, um sie zu haben? Sind sie nützlich in Bibliotheken, aber nicht in Anwendungen? Sind sie überall nützlich, außer in kleinen Projekten? Gedanken?

Antworten:


16

Nicht Präfixe nennen das Gleiche wie Namensräume , mit der Ausnahme , dass es in einer Art und Weise getan , die weniger nützlich und schwieriger zu lesen / Parse? Beantwortet sich die Frage nicht von selbst?


Nur ein Präfix am Anfang eines Bezeichnernamens einzufügen, ist nicht dasselbe wie die Verwendung einer Sprachfunktion wie Namespaces. In C ++ können Sie beispielsweise sagen, dass Sie usingein bestimmter Namespace sind und das Präfix dann nicht am Anfang von Bezeichnern in diesem Namespace stehen müssen.
compman

2
@ user9521 - das ist mein Punkt ...
Nicole

+1 Der einzige große Vorteil von Namespaces ist, dass Sie das Präfix überspringen / kürzen können, wenn es nicht benötigt wird - in dem Namespace, in dem das jeweilige Objekt definiert ist, durch using, durch import xxxxxxxxx as yyyusw.

1
Da die meisten Programmierer faul sind, würden Sie es lieber deklarieren using SDL;oder SDL_*überall tippen müssen ?
Berin Loritsch

2
+1, aber ich denke, Sie meinten wirklich "weniger nützlich, schwieriger zu lesen und nicht vom Compiler verifiziert".
Larry Coleman

5

Die meisten (alle?) Sprachen mit Namespaces sind in der Regel objektorientiert. Oft ist ein für Menschen lesbarer Name für einen Typ angemessen, obwohl es mehrere inkompatible Implementierungen gibt. (Dies wirft andere Probleme bei der objektorientierten Wiederverwendung auf, aber darum geht es in dieser Frage nicht). In Java haben Sie beispielsweise einen Timer, der für Hintergrund-UI-Aufgaben verwendet wird, und einen Timer, der für Hintergrund-Anwendungsaufgaben (nicht an AWT / Swing gebunden) verwendet wird. Mit dem Namespace können Sie diese gleichnamigen Objekte in verschiedenen Unter-APIs speichern.

Der Grund für die Entstehung von Namespaces lag in der unvernünftigen Aufgabe, vorauszusehen, wie andere Entwickler ihre Objekte benennen werden. C ++ führte das Konzept ein (oder war zumindest die erste Sprache, mit der ich mit dem Konzept konfrontiert wurde), und es war hilfreich, obwohl es keine Richtlinien für Best-Use-Methoden gab. Java hat das Konzept angepasst und einige "Best Practices" hinzugefügt, die Ihren Firmennamen in den Namespace aufgenommen haben. Auf diese Weise mussten Sie sich nur um Ihr eigenes Unternehmen kümmern.

Das Präfixieren kann ziemlich chaotisch werden. Wann wenden Sie es an? Wann wenden Sie es nicht an ? Erhalten Strukturen / Klassen / globale Methoden das Präfix? Was ist mit Methoden? Was ist mit Eigenschaften in der Struktur? Ich habe all diese Dinge im Code gesehen, obwohl zum Glück nicht alle auf einmal. Namespaces bieten eine gewisse Vorhersehbarkeit für all diese Fragen und machen sie eher zu einem Sprachmerkmal als zu einer persönlichen "Best Practice".


Haskell hat Namespaces (Module) und ist nicht objektorientiert.
Jeremy Heiler

3

Ich halte Namespaces für eine großartige Idee. Sie helfen dabei, Namenskonflikte zu vermeiden, indem sie den Umfang eines Namens einschränken. In Java - Paketen, wird die vorgeschlagene Paket Namenskonvention auf Domain - Namen basieren, die sollte eindeutig sein, die dazu beitragen , Namenskonflikte über benutzerdefinierte Bibliotheken verhindern. Insgesamt machen sie die Benennung im weiteren Sinne etwas einzigartiger, während der Programmierer dennoch ein bisschen mehr Freiheit bei der Benennung seiner Stücke hat, ohne dass er sich an eine undurchsichtige Benennungskonvention halten muss.


1
Im Fall von Javas spezifischer Konvention hat jedoch nicht jeder eine Website. Wenn Sie Ihr Programm jemals von einer Website auf eine andere verschieben (z. B. Sourceforge auf Github), ist es zwar sinnvoll, aber unpraktisch, Pakete zu ändern, wenn andere Dinge von Ihrem Code abhängen.
compman

1
Die Konvention von Java gilt für Ihre Organisation und nicht für den Ort, an dem sie gehostet wird. Sie können sich einfach als Organisation deklarieren und damit fertig werden. Es gibt auch das Problem, dass URLs Zeichen zulassen, die in Paketnamen nicht verwendet werden können. Aber wir werden nicht dorthin gehen. Verwenden Sie für Sie einfach "me.user9521" als Ihren Paketnamen, und Sie sind festgelegt.
Berin Loritsch

1
Die Konvention befasst sich nicht mit Web-Namen, sondern mit Domain-Namen. Sie können eine Domain ohne Website haben.
David Thornley

1

Namespaces / Module / Pakete sind nützlich, um Namenskonflikte zu vermeiden. Das gleiche gilt für das Namenspräfix, aber Namespaces bieten den zusätzlichen Komfort, Symbole in den aktuellen Namespace zu importieren, sodass Sie sich nicht um den gesamten Namespace :: * kümmern müssen.

Einige Sprachen (wie Python) erweitern diese Fähigkeit, indem Sie nur bestimmte Symbole in Ihr aktuelles Modul importieren oder Symbole unter einem anderen Namen importieren können. Dies ist nützlich, wenn Sie nur an einigen Klassen / Funktionen / Konstanten interessiert sind oder wenn einige der Symbole mit Symbolen in Ihrem Namespace in Konflikt stehen, andere jedoch nicht.

In einigen Sprachen (wie Ruby) können Sie die Methoden eines Moduls in Ihre Klasse aufnehmen. Dies ist nützlich für Polymorphismus und Generika. Wenn Sie beispielsweise über mehrere Klassen verfügen, deren Iteratoren auf dieselbe Weise funktionieren, können Sie Methoden aus einem separaten Modul in alle diese Klassen mischen, das Methoden zum Sortieren und Filtern der Daten im Objekt bereitstellt. Dies ermöglicht sowohl has aBeziehungen als auch is a(Vererbungs-) Beziehungen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.