The problems with Avoiding Smurf Naming classes with namespaces

The point of namespaces is so you can have classes of the same name from different libraries without them colliding. When you need to use the same named class from both you need to remove the ambiguity by prefixing one or both with its namespace scope.

That said, it's not really that bad to have a bunch of Smurf classes if Smurf tells you something specific about the class. The class names should be descriptive enough to give you some information about what the class does.

      Session
       ^   ^
      /     \
DBSession   HttpSession

Similarly a DBSession might take a DBRequest object which returns a DBResponse object. The HttpSession might also operate on HttpRequest and HttpResponse objects.

These are Smurf classes with a purpose.

They might live in the MyCompany namespace but MyCompanyHttpSession and MyCompanyDBSession does not give you any more information than you had before. In this case drop the Smurf and make it a namespace.

MyCompany.HttpSession

I've run up against this same point of confusion before and it's usually really a question of do we include the kind of thing it is as part of it's name.

You mention SmurfConfiguration and WartmongerConfiguration as potential kinds of configurations. You indicate that you removed the adjective (its kind) to its namespace so that what you're left with is just the vanilla Configuration. I would avoid doing that.

It's like deciding that strawberry ice cream is just ice cream in the strawberry namespace and likewise with chocolate, but what's happened is you've divorced the adjective that gives it its identity from the thing itself. It's not ice cream in the strawberry category. It's strawberry ice cream -- a kind of ice cream.

Let's imagine that in your app, you import the Strawberry.IceCream class and then start instantiating directly from IceCream.

var ic = new IceCream(); //actually I'm strawberry ice cream

This may seem well and good, up until the moment you end up importing another IceCream class. Now you're back to the original problem of having to somehow distinguish between them, which is problematic. What you wanted all along was:

var sic = new StrawberryIceCream();
var cic = new ChocolateIceCream();

Namespaces are better left to avoid potential conflicts between third parties who might incidentally represent the same concepts in their libraries. When one developer creates a library or project, however, he should name each concept uniquely and use namespaces as folders for organization only. Often the name of the folder will be found in the name of the concepts it organizes and that's okay.

It is definitely a good rule of thumb that if you've got a common prefix on a bunch of classes, then they probably deserve to go in their own namespace. To deal with the problem then, when you need to use similarly named classes from two namespaces:

1) Alias the namespaces, though I'd make it short and to the point, any natural abbreviation, maybe even just 1 letter:

using Sm = Smurf;
using W = Wartmonger;

Then always prefix wherever used and name instances appropriately:

Sm::Configuration smConf; 
W::Configuration wConf;

2) Alias the class, as suggested in other answer.

using SmConf = Smurf.Configuration;

3) Any library you have control over, consider not using the term 'Configuration'. Use thesaurus: e.g. 'Settings', 'Model', 'Parameters'. Might be more meaningful to the context anyway: E.g. if Smurf was some sort of numerical analysis module you'd written perhaps 'Parameters' would be better for its configuration. Use the particular vocabulary associated with a module's context to your advantage to come up with unique names that hold uniqueness even when mixed into other namespaces. I feel this might be kind of an answer to OP question 2.

4) Refactor code so that you don't have to mix the use of configuration from two different places. Details of that are up to you.

5) Combine the two configurations into one before you pass it into your class. Use a combined conf class to represent:

struct Conf {
    SmurfConfiguration smurf;
    WartmongerConfiguation wart;
}

The short member variable names are now kind of achieving the same thing as aliasing the class/namespace.

Seems strange that adding one point to the name bothering you.

Wartmonger.Configuration configuration = Wartmonger.Configuration .new();

// vs

WartmongerConfiguration configuration = WartmongerConfiguration.new();

If both Smurf and Wartmonger configurations used together in one place, but separatly they are used in multiple places - then namespace is definitely good approach.

Having namespace will give possibility to use "clean" names in internal code, where with prefixes you end up using SmurfConfiguration inside SmurfService's internal code, which can become annoying everytime you will open that code.