web-dev-qa-db-ja.com

同じクラスと名前空間名

名前空間とクラスに名前を付ける方法に問題があります。私はすでにすべての種類の問題を引き起こすので、それらが同じ名前を持つべきではないとすでに考えました。私にとって最も注目すべき問題は、クラスを完全に修飾するか、エイリアスを作成する必要があることです。ここに私が持っているものがあります：

Model.DataSource.DataSource
Model.DataSource.FileSystemDataSource
Model.DataSource.JsonDataSource
Model.DataSource.XmlDataSource
Model.DataSource.DataSourceConstraints
Model.DataSource.DataSourceStorage
Model.DataSource.DataTable
... // more others

Model.QueryStorage.QueryStorage
Model.QueryStorage.FileSystemQueryStorage
... // more others

Model.Project.Project
Model.Project.ProjectFactory

ご覧のとおり、3つのクラスがあり、それらが含まれているパッケージと同じ名前が付けられています。そのうちの2つはインターフェイスなので、Iを前に付けることを検討できますが、この規則は本当に好きではありません。また、ProjectUtilsなどのパッケージに名前を付けるという提案も聞きました。しかし、これらはユーティリティではなく、正当なドメインオブジェクトであると思います。 usingを使用して別名を付けることもできますが、Projectの名前はProjectよりも優れていますか？

重複せずにクラスにわかりやすい名前を付ける方法がわかりません。

c#interfacesnamingpackagesnamespace
4
Łukasz

名前空間に含まれている型と同じ名前を付けないようにしてください。私はあなたが使用できるいくつかのアプローチがあると思います：

  • 複数化：Model.DataSources.DataSource

    これは、名前空間の主な目的が同じ基本型から継承する型、または同じインターフェイスを実装する型を含めることである場合に特に効果的です。

  • 短縮：Model.QueryStorage

    名前空間に含まれる型の数が少ない場合、その名前空間はまったく必要ない可能性があります。

  • エンタープライズ化：Model.ProjectSystem.Project

    これは、特に製品の重要な部分で機能する場合があるため、独自の名前を付ける必要があります。

そのうちの2つはインターフェースなので、Iをプレフィックスとして付けることを検討できますが、この規則は本当に好きではありません。

あなたのコードが他の人（つまり、ライブラリ）で使用されている場合、またはコードの新規参入者を混乱させたくない場合は、本当にそうすべきです。

9
svick

.NET設計ガイドラインでは、インターフェースにI接頭辞が必要です。クラスには単数形（Collectionを実装するすべてにIEnumerableサフィックス）と名前空間には複数形をお勧めします。

4
Dmitry Nogin

異なる会社の名前空間が同じ名前になるのを防ぐために、名前空間の名前の前に会社名を付ける必要があります。

例：

Fabrikam.Math
Litware.Security

最終的には、名前空間は次の構造を持つ必要があります。

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
0
Tristan