I have a small issue with namespace and class naming. Here is a practical example:
ResourceLayer.cs - Public component that holds the manager and the map provider, implements an interface ResourceMapProvider.cs - Provides a bitmap representation of the resources ResourceManager.cs - Is a repository of resources with some utility methods Resource.cs - A resource entity
But I’m going to have a larger number of layers, each specialized so this is going to be replicated a lot.
I have no idea how to namespace it in a conceptually correct fashion.
Here are my ideas and why I believe they don’t work:
App.ResourceLayer - Same name as class, bad practice and had some scope issues App.ResourceUtils - Good name, but ResourceLayer.cs doesn't really fit into the namespaces and I wouldn't know where to put it App.Resource - Same name as a class that would be in it, scoping issues (App.Resource.Resource) App.Resources - Confusing (App.Resources.Resource) , doesn't really fit the layer part (App.Resources.ResourceLayer)
So, does anyone have any naming ideas?
ResourceEntity.cs and you can let it’s namespace be
Resource. Same with
Elevation and all the others.
That solves the naming problem. Be sure you’re comfortable with this cookie cutter design. It’s easy to obsess on creating a predictable structure to work within and ignore problems caused because you insist on sticking with it rather than rethink the structure.
According to the C# naming guidelines, namespaces should be plural, eg.
ResourceLayers rater than
ResourceLayer. This avoids collisions between class and namespace name.
That said, you might not even need a separate namespace for each layer since in the naming scheme you suggest, the name of the layer is used in the names of all the components of the layer. So you don’t really need a namespace to disambiguate. Having too many unnecessary namespaces leads to clutter.