C++名前空間の使用法と命名規則

Question

プロジェクトでは、名前空間の使用について合意に達しようとしています。 最初のレベルは「productName」、2番目は「moduleName」と決めました。モジュールは、ユーティリティモジュールの一種である場合

productName::moduleName 

は今第三の名前空間を追加するには問題はありません。たとえば、 "str"を追加するには：productName :: utilityModuleName :: str - すべての "文字列"関連のものが移動する場所を分割します。

モジュールが主要なビジネスモジュールである場合、私たちは多くの機会とほとんど合意がありません。例えば

class productName::mainModuleName::DomainObject 

と

class productName::mainModuleName::DomainObjectSomethingElseViewForExample 

は、なぜ私たちは、内部プライベートではないクラスやない名前空間を作成する必要があります

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

の両方ですることができますか？ すべてのメソッドが静的であるクラスを作成するのはなぜですか（このクラスがテンプレートパラメータになる場合は例外です）。

プロジェクトは1Gbのソースコードで構成されています。 したがって、C++の名前空間でモジュールを分割するベストプラクティスは何ですか？

Answer 1

ためにはどのような名前空間：あなたが命名confilctsを持っていないだけので

名前空間は、コンテキストを確立するためのものです。

一般規則：

あまりにも多くのコンテキストを指定するには必要ありません、それは価値があるよりも多くの不便が発生します。

だから、あなたはあなたの最良の判断を使用したいが、それでもこれらの2つのルールは、次のとおりです。名前空間 を使用するときに、名前空間

を使用すると、あまりにも具体的なことはいけないとき

• はあまり一般的ではいけません

  名前空間名を使用する方法や、関連するコードグループに基づいて名前空間を使用する方法については厳密ではありません。

  一般的すぎる名前空間は役に立ちません理由：製品名で始まる名前空間を分割して

  問題は、あなたは多くの場合、コードの構成要素、または共通であるいくつかの基本ライブラリを持っているということです複数の製品に

  また、Product1内でProduct2名前空間を使用しないため、明示的に指定するのは無意味です。 Product2のファイルをProduct1の中に含める場合、この名前変換はまだ有効ですか？

  あまりにも特定されている名前空間は役立たない理由：あなたはあまりにも特定されている名前空間を持っている場合は

  は、これらの異なる名前空間の間の線があいまいに開始します。あなたはお互いに前後に名前空間を使い始める。現時点では、共通のコードを同じ名前空間で一緒に一般化する方がよいでしょう。テンプレート対すべての静的で

  クラス：

  が

  「なぜ私たちは、内側ではない プライベートクラスではなく名前空間を作成する必要があり は、なぜ我々は、すべての メソッドは静的なクラスを作成する必要があります」

  いくつかの違い：

  • の名前空間が
  • 名前空間はエイリアスすることができるusingキーワードを使用することによって暗示することができ、クラスはタイプであり、
  • 名前空間に加えることができるtypedefさすることができます。あなたはクラスが
  • 名前空間を使用して、プライベートメンバーや保護されたメンバーを持つことができますクラスで前方宣言
  • を持つことができ、新たな派生クラスを作成せずに追加することはできません
  • 直接
  をいつでもに機能を追加し、それに追加することができます

  を：

  クラスは分割する正確にどのようにテンプレート

  で使用することができます

  "プロジェクトは1Gbソースの コードで構成されています。だから、何 C++での名前空間の 除算モジュールへのベストプラクティスです？」

  することは、正確なソースコードなしで、あなたのコードを分割する方法を正確に言うにはあまりにも主観的だ。論理的に聞こえるのにモジュールに基づいて分割します製品全体だけではありません。

Answer 2

これはすべて主観的ですが、私は3レベル以上深く行くことを躊躇します。ある時点では扱いにくいです。コードベースが非常に大きい場合を除いて、私はそれをかなり浅く保ちます。

私たちのコードをサブシステムに分割し、各サブシステムの名前空間を持っています。実際にサブシステム間で再利用可能な場合、ユーティリティのものは独自の名前空間に入ります。

Answer 3

名前空間を設計ツールとして使用しようとしているようですが、それは名前の衝突を防ぐためのものではありません。名前空間は必要ありません。

Answer 4

Iは、その用途に応じて名前空間を分割：

私は私はすべてのインターフェイス（純粋仮想クラス）を定義した別の名前空間を有します。

私は別の名前空間を持っています。ここでは、ライブラリクラス（dbライブラリ、処理ライブラリなど）を定義しています。

私は別の名前空間を持っています。そこには、私のコアビジネス（ビジネスロジック）オブジェクト（purchase_orderなど）があります。

私は、それを将来的には扱いにくくならない方法で定義すると思います。したがって、現在のデザインで取り巻く問題を確認できます。

あなたは彼らが大丈夫だと思うなら、あなたはそれと一緒に行くべきです。