web-dev-qa-db-ja.com

ライブラリのC＃名前空間とクラスの命名規則

C＃でさまざまな小さなユーティリティ関数を使用してライブラリを構築し、名前空間とクラスの命名規則を決定しようとしています。私の現在の組織は次のようなものです：

Company
Company.TextUtils
    public class TextUtils {...}
Company.MathsUtils
    public class MathsUtils {...}
    public class ArbitraryPrecisionNumber {...}
    public class MathsNotation {...}
Company.SIUnits
    public enum SISuffixes {...}
    public class SIUnits {...}

これは名前空間とクラスを整理する良い方法ですか、それとももっと良い方法がありますか？特に、名前空間とクラス名に同じ名前があるようです（例：Company.TextUtils名前空間とTextUtilsクラス）は単なる複製であり、このスキームの方が優れている可能性があることを示唆しています。

c#namingnamespace
27
user

命名戦略が他のコードからどれほど効果的であるかを判断することは非常に困難です。

名前空間は、コードベースの広範な構造のどこに適合するかについて何らかの考えを与える必要があり、クラス名は通常、その領域内でそれが表す機能や概念の種類を表します。

注意点はさておき、具体的な例では、「Util」タイプのクラスがさらに増える可能性がある場合は、Company.Utils.Mathsなどに配置することを検討します。複数のユーティリティに共通の機能を追加する必要がある場合エリア、あなたはすでにそれのための自然な場所を持っています。

9
richzilla

Microsoftと一致するために従う必要がある多くのルールを含む素敵なドキュメントがあります： Framework Design Guidelines 。

変更する必要がある1つのこと： しないでください名前空間としてクラスに名前を付けます。 これはコンパイラの混乱を招きます。しないでください。名前空間のいずれかのクラスに適した名前を見つけます。

30
nvoigt

C＃または.NETエコシステムを使用して久しぶりなので、現在推奨されているベストプラクティスは何なのかわかりません。次のように名前を変更することをお勧めします。

Company
Company.Text
    public class TextUtils {...}
Company.Math
    public class MathUtils {...}
    public class ArbitraryPrecisionNumber {...}
    public class MathsNotation {...}
Company.SI
    public enum SISuffixes {...}
    public class SIUnits {...}

ここで行ったことは、名前空間名から「Utils」を削除することです。 Company.Text名前空間には、notテキストユーティリティクラスであるクラスが含まれる可能性があるため、「Util」は名前空間に含めないでください。 。 Company.Math名前空間は既ににArbitraryPrecisionNumberが含まれていますが、これは「ユーティリティ」ではないようです。

名前空間から「Util」を削除すると、同じ名前のものが2つあることで発生する可能性のある混乱も解消されます（Robertの回答で述べたように https://softwareengineering.stackexchange.com/a/340440/13156 ）

コードを整理するもう1つの方法：

Company
Company.Util
    public class TextUtils {...}
    public class MathUtils {...}
Company.Math
    public class ArbitraryPrecisionNumber {...}
    public class MathsNotation {...}
Company.SI
    public enum SISuffixes {...}
    public class SIUnits {...}

この場合、すべてのユーティリティクラスは同じ名前空間にあります。ユーティリティクラスしかなかったため、Company.Text名前空間はありません。

個人的には、最初のオプションがもう少し明確だと思います。

6
FrustratedWithFormsDesigner

名前空間とその内部のクラスに同じ名前を使用すると問題が発生します。

  • 名前空間に複数のクラスが含まれている場合、なぜ他のクラスがそこに置かれるのですか？名前空間の名前の目的は、1つだけではなく、その中のクラスをall記述することなので、正しくありません。たとえば、名前空間にJsonSerialization、BinarySerialization、およびXmlSerializationクラスがある場合、名前空間にXmlSerializationという名前を付けるのは理にかなっていますか？

    通常起こることは、既存の名前空間からのクラスの抽出、または複数のクラス間のマージまたは他の再編成により、majorクラス;マイナークラスは、元のクラスとわずかに関連しているため、徐々に配置されます。たとえば、名前空間LogParserには単一のクラスLogParserが含まれている可能性があり、パーサーに非常に関連しているため、誰かがLogConverterを配置し、次にLogSearcher、ここでの問題は、名前空間の名前が変更されなかったことです。LogConverterが追加されるとすぐに、名前はLogsProcessingまたは単にLogs。

  • 名前空間に含まれるクラスが1つだけの場合、それはmightがコード編成内の問題の兆候である可能性があります。

    私は何度か、適切なSOLID原則を持つ単一のクラスがコードベースの他のクラスとは非常に異なり、専用の名前空間に置かれる状況を何度か見ましたが、そのようなケースはまれです。多くの場合、これは問題を示しています。同様に、単一のメソッドを含むクラスを持つことを妨げるものは何もありませんが、多くの場合、そのようなクラスは問題を示します。

    名前空間に含まれるクラスが1つだけの場合でも、通常、クラスに名前を付ける場合はより具体的に、名前空間に名前を付ける場合はより一般的な方法があります。特に、ある時点でABC形式で記述されたファイルをDEF形式に変換するアプリケーションを想像してみてください。変換は、ビジネスオブジェクトへの/からの逆シリアル化/シリアル化を必要とせず、AbcToDefConverterと呼ばれる変換クラス自体に含めるのに十分短い正規表現の束を適用することによって行われます。すべての変換ロジックは、約10の相互依存メソッドで約80のLLOCを使用します。既存のクラスを分割したり、追加のクラスを作成したりする必要がまったくないようです。アプリケーションの残りの部分は変換とは関係がないため、クラスを既存の名前空間の他のクラスとグループ化することはできません。したがって、AbcToDefConverterという名前空間を作成します。その点で本質的に問題はありませんが、Convertersなどのより一般的な名前を使用することもできます。 Pythonなどの言語では、短い名前が優先され、繰り返しがスローされるため、converters.Abc_To_Def。

したがって、-名前空間には、含まれているクラスとは異なる名前を使用します。クラスの名前はクラスが実行していることを示す必要があり、名前空間の名前は、その中に置かれたすべてのクラスに共通することを強調する必要があります。

ちなみに、ユーティリティクラスは本質的に間違っています：任意精度の算術などの特定の何かを含めるのではなく、方法を見つけられなかったすべてのものをむしろ含みます他のクラスで。これは、デスクトップのMiscellaneousディレクトリと同じように、単に不適切な名前です。これは、組織化されていないことを示しています。

ネーミングが存在するのには理由があります。後で物を探す必要があるときに、あなたの人生をより簡単にするためです。グラフを描く必要がある場合は、「グラフ」または「プロット」を検索してみてください。アプリが請求書を生成する方法を変更する必要がある場合は、「invoic [e/ing]」または「bill」を検索します。同様に、自分に言い聞かせるケースを想像してみてください。「この機能はおそらくその他にも見つかるはずです」。できません。

.NET Frameworkを見てください。これらのクラスのほとんどはユーティリティクラスではありませんか？つまり、彼らはビジネスドメインとはほとんど関係がありません。金融アプリ、eコマースWebサイト、または次世代の教育プラットフォームで作業している場合、XMLのシリアル化、ファイルの読み取り、SQLクエリの実行、またはトランザクションの実行は、すべてユーティリティです。ただし、これらはUtilitySerializationまたはUtilityTransactionと呼ばれず、Utility名前空間にありません。それらには適切な名前が付いているので、必要なときに簡単に見つけることができます（そして.NET開発者に感謝します！）。

アプリでよく再利用するyourクラスについても同様です。これらはユーティリティクラスではありません。それらは特定のことを行うクラスであり、それらが行うことは実際にはクラスの名前でなければなりません。

単位と単位の変換を処理するコードを作成したとします。あなたはそれをUtilityと名付け、同僚から嫌われるかもしれません。または、UnitsおよびUnitsConversionという名前を付けることができます。

5
Arseni Mourzenko