Proper namespace for many concrete implementations of an abstract class

Question

I'm in the process of designing a .NET library and I'm looking for some feedback concerning class organization and namespaces.

Suppose that I have an abstract Message class that is in the root namespace Foo. Message has many concrete implementations for different message types. Given that there will be many concrete implementations (let's assume 20, or even more), is it expected that these concrete types live in a separate namespace, something like Foo.Messages?

I'm worried about cluttering the namespace with too many concrete Message classes that users of my library will rarely need to use directly. What are you expectations when using a library?

edit:

Also, if I do group the concrete classes into Foo.Messages, should the abstract class live there as well, or should that remain in Foo?

Answer 1

If the users of your library won't be constructing your concrete implementation classes (they go through a factory pattern to get instances, and access the instances only through the abstract base type), consider making your concrete implementation classes internal. This will keep them out of the user's code completion choices.

Grouping all the concrete implementation classes under a Foo.Messages namespace sounds fine. You don't want to go too far the other way either - creating a lot of namespaces for minor things is a huge irritation to the user.

Answer 2

Kind of a loaded question, but if the issue is having too many classes hampering discoverability, is part of the solution perhaps making some of these classes internal rather than public? If users won't ever instantiate these directly, that might be part of the solution to your clutter problem.

It really does depend quite a lot on the nature of the API you're designing, and to some degree on taste. Often there's a single primary class or set of classes that your users will be going straight to most of the time, like NLog's Logger, or AutoMapper's Mapper, or NoRM's Mongo, or class factories in general. Those should be front and center and discoverable, and you could make a strong case that it's best to have that in your root namespace.

For other classes (ones that are more about the implementation and less about the API), obviously you want to be organized, but you can play with a pretty free hand and organize in a way that feels natural to you, as long as the parts of the API that users need to find are the most visible. Foo.Messages seems like a totally reasonable way to start. On the other hand, if 90% of your classes are Message subclasses, but there's an important distinction between Server messages and Client messages, or Purple messages and Plaid messages, maybe Foo.Server or Foo.Plaid are the right kinds of namespaces for you.