Question

Suppose I’m making a new library, Jokes, with a small API. In the interest of making my API easy to use I put it in the base namespace:

namespace Jokes

    --> public interface IJoker
        --> string Joke();

    --> public static class Jokers
        --> public static IJoker NewSlapstickJoker()
        --> public static IJoker NewAbsurdJoker()
        --> public static IJoker NewCheesyJoker()

The implementations of the Jokers are internal:

--> internal class SlapstickJoker : IJoker
--> internal class AbsurdJoker : IJoker
--> internal class CheesyJoker : IJoker

---

Now I’m pretty sure the following is a guideline to follow (could someone please verify?):

• Do not access types from subnamespaces from the root namespace. (For example, the types in System are ignorant of types in System.Drawing).

Does this guideline apply to internal classes? To avoid polluting my root namespace, I would like to put my internal classes in Jokes.Internal. This would mean that a type in the Jokes namespace (Jokers) would know about types in the subnamespace Jokes.Internal. Is this ok?

Answer 1

To avoid polluting my root namespace, I would like to put my internal classes in Jokes.Internal. This would mean that a type in the Jokes namespace (Jokers) would know about types in the subnamespace Jokes.Internal. Is this ok?

Yes, that’s fine. The main guidance about not having types in a namespace rely on types within a “sub” namespace really is more about the public API. The internal classes, and namespaces used only by internal types, is really an implementation detail, and outside of any guidance of the sort.

I would stick to something consistent that you find makes sense. Using an Internal namespace seems reasonable (though I’d potentially do something like namespace Jokes.Implementations).

Also, given that your Jokers class is constructing new instances, it’s basically a factory. You might want to consider naming something more like JokerFactory to make this obvious. Jokers, to me, would suggest that there would be a collection of Joker instances contained within the class, not a set of factory methods.