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

StackOverflow https://stackoverflow.com/questions/603378

  •  03-07-2019
  •  | 
  •  

質問

プロジェクトでは、名前空間の使用について合意に達しようとしています。 最初のレベルは＆quot; productName＆quot;とすることにしました。 2番目は＆quot; moduleName＆quot;です。

productName::moduleName

モジュールがユーティリティモジュールの種類である場合、3番目の名前空間を追加しても問題ありません。たとえば、＆quot; str＆quot;を追加するには：productName :: utilityModuleName :: str-すべての「文字列」がスペースを分割する関連するものは行きます。

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

例

class productName::mainModuleName::DomainObject

and 

class productName::mainModuleName::DomainObjectSomethingElseViewForExample

両方にいることができます

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

なぜ名前空間ではなくプライベートクラスではなく内部クラスを作成する必要があるのですか？ すべてのメソッドが静的であるクラスを作成する理由（このクラスがテンプレートパラメーターになる場合を除く）

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

役に立ちましたか？

解決

名前空間の用途：

名前空間は、コンテキストを確立することのみを目的としているため、名前付けコンフリクトはありません。

一般的なルール：

あまりにも多くのコンテキストを指定する必要はなく、価値があるよりも不便です。

したがって、最善の判断を下したいが、それでも次の2つのルールに従ってください：

  • 名前空間を使用するときにあまり一般的ではありません
  • 名前空間を使用するときは、あまり具体的にしないでください

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

一般的すぎる名前空間が役に立たない理由：

製品名で始まる名前空間の分割の問題は、多くの場合、コードのコンポーネント、または複数の製品に共通のベースライブラリがあることです。

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

特定性が高すぎる名前空間が役に立たない理由：

特定の名前空間が非常に限定されている場合、これらの個別の名前空間の間の線があいまいになります。相互に内部の名前空間を使い始めます。現時点では、共通のコードを同じ名前空間の下で一緒に一般化することをお勧めします。

すべての静的vsテンプレートを含むクラス：

  

＆quot;なぜ内部を作成するのではなく   名前空間ではなくプライベートクラス？   なぜ私たちはすべてのクラスを作成する必要があります   メソッドは静的です＆quot;

いくつかの違い：

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

正確な分割方法：

  

＆quot;プロジェクトは1 GBのソースで構成されています   コード。だから、へのベストプラクティスは何ですか   の名前空間でモジュールを分割する   c ++？＆quot;

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

他のヒント

これはすべて主観的ですが、3レベル以上深くすることをheします。ある時点で扱いにくくなります。したがって、コードベースが非常に大きくない限り、かなり浅く保ちます。

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

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

使用法に応じて名前空間を分割します：

すべてのインターフェイス（純粋な仮想クラス）を定義した個別のネームスペースがあります。

ライブラリクラス（dbライブラリ、処理ライブラリなど）を定義した別のネームスペースがあります。

そして、コアビジネス（ビジネスロジック）オブジェクト（purchase_orderなど）がある別のネームスペースがあります。

それをある意味で定義することについては、今後の扱いが難しくなることはないと思います。そのため、現在の設計に伴う問題を確認できます。

そして、あなたがそれらが素晴らしいと思うならば、あなたはそれで行くべきです。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top