The problems with Avoiding Smurf Naming classes with namespaces

Question

I pulled the term smurf naming from here (number 21). To save anyone not familiar the trouble, Smurf naming is the act of prefixing a bunch of related classes, variables, etc with a common prefix so you end up with "a SmurfAccountView passes a SmurfAccountDTO to the SmurfAccountController", etc.

The solution I've generally heard to this is to make a smurf namespace and drop the smurf prefixes. This has generally served me well, but I'm running into two problems.

1. I'm working with a library with a Configuration class. It could have been called WartmongerConfiguration but it's in the Wartmonger namespace, so it's just called Configuration. I likewise have a Configuration class which could be called SmurfConfiguration, but it is in the Smurf namespace so that would be redundant. There are places in my code where Smurf.Configuration appears alongside Wartmonger.Configuration and typing out fully qualified names is clunky and makes the code less readable. It would be nicer to deal with a SmurfConfiguration and (if it was my code and not a library) WartmongerConfiguration.

2. I have a class called Service in my Smurf namespace which could have been called SmurfService. Service is a facade on top of a complex Smurf library which runs Smurf jobs. SmurfService seems like a better name because Service without the Smurf prefix is so incredibly generic. I can accept that SmurfService was already a generic, useless name and taking away smurf merely made this more apparent. But it could have been named Runner, Launcher, etc and it would still "feel better" to me as SmurfLauncher because I don't know what a Launcher does, but I know what a SmurfLauncher does. You could argue that what a Smurf.Launcher does should be just as apparent as a Smurf.SmurfLauncher, but I could see `Smurf.Launcher being some kind of class related to setup rather than a class that launches smurfs.

If there is an open and shut way to deal with either of these that would be great. If not, what are some common practices to mitigate their annoyance?

Answer 1

You raise some good points.

1. With regards to having duplicate classes, you can alias classes in C#. Use for example using ColorScheme = The.Fully.Qualified.Namespace.Outlook2007ColorScheme; See this post on StackOverflow. You've not indicated your programming language but I have inferred it from what you've written. So where you're dealing with two different projects, you can alias them as SmurfConfiguration and WartmongerConfiguration which would free ambiguity when consuming both classes.

2. As a service is exposed to external application(s) I see no problem in branding the service with your application name, so in this case SmurfService would be valid as it would actually disambiguate groups of services in the consuming application.

I feel that namespaces should be used to avoid this style of naming. It makes it more difficult to grok the code and see at face value what a class is without reading MyCompanyMyProductMyAreaClassName. Using the aliasing technique allows you to reduce ambiguity where needed. The only time I think you should introduce complexity into your naming is, as I've pointed out in #2, when people will be consuming a service. This is where it makes perfect sense to have this style of naming because if the consumer has a variety of services it is consuming the ambiguity could be confusing.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.