c ++名前空間の使用法と命名規則
このプロジェクトでは、名前空間の使用法について合意に達することを目指しています。最初のレベルは「productName」、2番目のレベルは「moduleName」にすることにしました。
productName::moduleName
モジュールがユーティリティモジュールの一種である場合、3番目の名前空間を追加しても問題はありません。たとえば、「str」を追加するには：productName :: UtilityModuleName :: str-すべての「文字列」関連のものが入るスペースを分割します。
モジュールがメインのビジネスモジュールである場合、多くの機会があり、ほとんど合意がありません。
例えば
class productName::mainModuleName::DomainObject
そして
class productName::mainModuleName::DomainObjectSomethingElseViewForExample
両方にすることができます
namespace productName::mainModuleName::domainObject
class Data
class ViewForExample
名前空間ではなく内部クラスを作成する必要があるのはなぜですか？すべてのメソッドが静的であるクラスを作成する必要があるのはなぜですか（このクラスがテンプレートパラメーターになる場合を除く）？
プロジェクトは1Gbのソースコードで構成されています。では、C++の名前空間でモジュールを分割するためのベストプラクティスは何ですか？
名前空間の目的：
名前空間はコンテキストを確立することのみを目的としているため、名前空間の矛盾はありません。
一般規則：
あまりにも多くのコンテキストを指定する必要はなく、それが価値があるよりも多くの不便を引き起こします。
したがって、最善の判断を下しますが、それでも次の2つのルールに従います。
- 名前空間を使用するときはあまり一般的ではありません
- 名前空間を使用するときは、あまり具体的にしないでください
名前空間名の使用方法や、関連するコードグループに基づいた名前空間の使用方法についてはそれほど厳密ではありません。
一般的すぎる名前空間が役に立たない理由：
製品名で始まる名前空間を分割する際の問題は、コードのコンポーネント、または複数の製品に共通の基本ライブラリが含まれることが多いことです。
また、Product1内でProduct2名前空間を使用しないため、明示的に指定しても意味がありません。 Product1内にProduct2のファイルを含めていた場合、この命名変換は引き続き役立ちますか？
具体的すぎる名前空間が役に立たない理由：
あまりにも具体的な名前空間がある場合、これらの異なる名前空間間の境界線があいまいになり始めます。お互いの内部で名前空間を前後に使用し始めます。現時点では、共通のコードを同じ名前空間で一般化することをお勧めします。
すべての静的vsテンプレートを含むクラス：
「なぜプライベートクラスではなく名前空間ではなく内部クラスを作成する必要があるのですか？すべてのメソッドが静的であるクラスを作成する必要があるのはなぜですか？」
いくつかの違い：
- 名前空間は、
usingキーワードを使用して暗示することができます - 名前空間はエイリアス化でき、クラスは型であり、typedefすることができます
- 名前空間はに追加できます。いつでも機能を追加して直接追加できます
- 新しい派生クラスを作成せずにクラスを追加することはできません
- 名前空間は前方宣言を持つことができます
- クラスを使用すると、プライベートメンバーと保護されたメンバーを持つことができます
- クラスはテンプレートで使用できます
正確に分割する方法：
「プロジェクトは1Gbのソースコードで構成されています。では、c ++の名前空間でモジュールを分割するためのベストプラクティスは何ですか？」
正確なソースコードなしでコードを分割する方法を正確に言うのは主観的すぎます。モジュールに基づいて分割することは論理的に聞こえますが、製品全体ではありません。
これはすべて主観的ですが、3レベル以上深くすることを躊躇します。ある時点で扱いにくくなります。したがって、コードベースが非常に大きくない限り、かなり浅くしておきます。
コードをサブシステムに分割し、サブシステムごとに名前空間を設定します。ユーティリティのものは、実際にサブシステム間で再利用可能である場合、独自の名前空間に入ります。
名前空間をデザインツールとして使用しようとしているようです。それらはそのためのものではなく、名前の衝突を防ぐことを目的としています。衝突がない場合は、名前空間は必要ありません。
名前空間は、その使用法に応じて分割します。
すべてのインターフェース（純粋仮想クラス）を定義した別の名前空間があります。
ライブラリクラス（dbライブラリ、処理ライブラリなど）を定義した別の名前空間があります。
また、別の名前空間があり、コアビジネス（ビジネスロジック）オブジェクト（purchase_orderなど）があります。
ある意味でそれを定義することについては、将来的には扱いが難しくなることはないと思います。したがって、現在の設計を取り巻く問題を確認できます。
そして、あなたが彼らが大丈夫だと思うなら、あなたはそれと一緒に行くべきです。