c ++ Namespace-Nutzung und Benennungsregeln

Question

Auf dem Projekt, das wir versuchen, eine Einigung über die Namespace-Nutzung zu erreichen. Wir haben uns entschieden, dass die erste Stufe sein wird „product“ und das zweite ist „Modulname“.

productName::moduleName

Nun, wenn die Modul Art von Utility-Modul ist es kein Problem dritten Namensraum hinzuzufügen. Zum Beispiel hinzufügen „str“. Product :: utilityModuleName :: str - Raum zu teilen, wo alle „Strings“ bezogen werden, werden Sachen gehen

Wenn das Modul das Hauptgeschäft Modul ist, dass wir viele Möglichkeiten und so gut wie keine Vereinbarung haben.

Zum Beispiel

class productName::mainModuleName::DomainObject

und

class productName::mainModuleName::DomainObjectSomethingElseViewForExample

kann sowohl bei

namespace productName::mainModuleName::domainObject
class Data
class ViewForExample

Warum sollen wir nicht innere private Klassen erstellen und nicht Namespaces? Warum sollen wir Klasse schaffen, in dem alle Methoden statisch sind (mit Ausnahme von Fällen, in denen diese Klasse Template-Parameter sein wird)?

Projekt besteht aus 1Gb des Quellcodes. Also, was ist die beste Praxis-Module auf Namespaces in C ++ zu teilen?

Answer 1

Welche Namensräume sind für:

Namespaces sollen Kontext nur etablieren, so dass Sie die Benennung confilcts nicht haben.

Allgemein gilt:

Die Angabe zu viel Kontext nicht benötigt wird, und wird mehr Unannehmlichkeiten bereiten, als es wert ist.

So Sie Ihr bestes Urteil verwenden, aber immer noch diesen zwei Regeln beachten:

• Seien Sie nicht zu allgemein, wenn Namespaces mit
• Seien Sie nicht zu spezifisch, wenn Namespaces mit

würde ich nicht so streng sein, wie Namespace-Namen zu verwenden und einfach Namespace basiert auf einer verwandten Gruppe von Code zu verwenden.

Warum Namespaces, die zu allgemein sind, ist nicht hilfreich:

Das Problem mit dem Namespace mit dem Produktnamen beginnen teilt, ist, dass Sie oft eine Komponente des Codes haben, oder eine Basisbibliothek, die mehrere Produkte üblich ist.

Sie werden auch nicht so explizit mit Product2 Namespaces innerhalb Product1, seine Angabe es sinnlos ist. Wenn Sie Product2 die Dateien innerhalb Product1 wurden, einschließlich, dann ist diese Namensumwandlung noch nützlich?

Warum Namespaces, die zu spezifisch sind, ist nicht hilfreich:

Wenn Sie Namespaces, die zu spezifisch sind, beginnen die Linie zwischen diesen deutlichen Namensräume verschwimmen. Sie starten die Namensräume ineinander hin und her mit. Zu diesem Zeitpunkt ist es besser, den gemeinsamen Code zusammen unter dem gleichen Namensraum zu verallgemeinern.

Klassen mit allen statischen vs Vorlagen:

  

"Warum sollten wir innere schaffen nicht   Privatunterricht und nicht Namespaces?   Warum sollten wir schaffen Klassen, in denen alle   Methoden sind statisch "

Einige Unterschiede:

• Namensräume können mithilfe des using Schlüsselwort impliziert werden
• Spaces sein aliased, Klassen-Typen sind und typedef werden
• Spaces hinzugefügt werden; Sie können Funktionalität, um es jederzeit hinzufügen und direkt zu ihm hinzufügen
• Klassen können nicht ohne eine neue abgeleitete Klasse hinzugefügt werden
• Namespaces können vorwärts Erklärungen haben
• Mit Klassen können Sie private Mitglieder und geschützte Mitglieder haben
• Klassen können mit Vorlagen verwendet werden

Wie genau einzuteilen:

  

"Projekt besteht aus 1 GB Quelle   Code. Also, was ist die beste Praxis zu   divide Module auf Namensräume im   c ++? "

Es ist zu subjektiv, genau zu sagen, wie Sie Ihren Code ohne den genauen Quellcode zu teilen. obwohl Teilung basierend auf den Modulen klingt logisch, nur nicht das ganze Produkt.

Answer 2

Das ist alles subjektiv, aber ich würde gerne mehr als 3 Ebenen tief gehen. Es wird einfach zu unhandlich an einem gewissen Punkt. Also, wenn Ihr Code-Basis ist sehr, sehr groß ist, würde ich es halten ziemlich flach.

Wir teilen unseren Code in Subsysteme und haben einen Namespace für jedes Subsystem. Dienstprogramm Dinge würden ihre eigenen Namensraum gehen in der Tat, wenn sie wiederverwendbar über Subsysteme sind.

Answer 3

Es scheint mir, dass Sie versuchen, Namespaces als Design-Tool zu verwenden. Sie sind nicht dafür bestimmt sind, sollen sie Namenskonflikte vermeiden. Wenn Sie nicht über die Auseinandersetzungen haben, müssen Sie nicht die Namensräume benötigen.

Answer 4

Ich teile Namensräume in Abhängigkeit von seinen Verwendungen:

Ich habe einen eigenen Namensraum, wo ich alle meine Schnittstellen (rein virtuelle Klassen) definiert haben.

Ich habe einen eigenen Namensraum, in dem ich meine Bibliothek Klassen definiert haben (wie db Bibliothek, Verarbeitungsbibliothek).

Und ich habe einen eigenen Namensraum, in dem ich mein Kerngeschäft (Business-Logik) habe Objekte (wie PURCHASE_ORDER, etc).

Ich denke, es geht um es in einer Art und Weise zu definieren, die nicht schwer tut, wird in der Zukunft zu bewältigen. So können Sie die Schwierigkeiten überprüfen, die auf Ihrem aktuellen Design umgeben wird.

Und wenn Sie denken, sie sind in Ordnung, sollten Sie mit ihm gehen.