Avoiding conflicting namespace and class name

Question

Say I am developing a Calculator application. It has one class called: Calculator. Therefore my namespace structure would look like this:

MyCompany.Calculator.Core.Calculator

Unfortunately, this is not right because the same name should not be used for a namespace and a type in it. This is thoroughly explained in this other SO question. One of the answer to that question suggests to solve the ambiguity by using an Util suffix for the namespace, which would then look like this:

MyCompany.CalculatorUtil.Core.Calculator

This solves the naming ambiguity in the programming language. However, this kind of naming is in contradiction with good DDD naming practices: because Util seems to be a "weasel word" according to this article on naming in the ubiquitous language and these should be avoided.

What is the best way to avoid a conflict here in the case of a Calculator?

The application I am developing is much more complex than a simple calculator, however the principle still stands.

• Neil: "I am developing a Calculator application" "The application I am developing is much more complex than a simple calculator." I think you've answered it on your own. Give your namespace a proper name to represent "much more complex than a simple calculator".
• w0051977: @Neil, the principle still stands to the application I am developing.
• Emerson Cardoso: If you choose some appropriate name, all conflicts can be avoided by the client of your classes, by simply using the full qualified name if necessary.
• Kilian Foth: Tell us what other leaf classes there are besides Calculator, and we'll tell you what to call the higher-level package.
• Neil: You can resolve the namespace problem both in this case and in principle by providing a more comprehensive name to the namespace. No set can contain itself, and the relationship of a class to a namespace should be considered a component of a whole module. Therefore the names shouldn't clash if named properly.

Answer 1

Is the name of your application 'Calculator'? if it is you may find that that name has already been used.

I would also advise you NOT to use myCompany as part of the namespace. I know its a standard way but company names change.

Just have:

MyApplicationsRealName.App
MyApplicationsRealName.LibraryName.ClassName

• doubleYou: What if the application's name changes?
• Ewan: of course this can happen, but in my experience it is less likely. Companies get bought, sold and rebranded much more often than they change the name of the products and sometimes a new product name means new code anyway
• Ewan: also, its just the one application that you need to deal with. not every bit of code the company has ever written
• doubleYou: I guess we could argue whether you actually need to change the namespace when the company's name changes, but my question wasn't really serious. I think your suggestion should work fine. Unless, of course, you have an App class - then you're in trouble...
• doubleYou: My bad! I assumed this was the project that produces the executable. Okay, I'm out of objections, fake or otherwise.

Answer 2

Say I am developing a Calculator application. It has one class called: Calculator

What do you think will the class name Calculator stand for? What do expect to find there, just by reading that name? The UI, the domain logic, data, application start code? You cannot tell, this class name is way too ambigous to make sense.

So if I were going to design a Calculator application, there could be an CalculatorDialog class for the UI, a CalculatorController or CalculatorLogic for the domain logic, a CalculatorPresenter or CalculatorViewModel when making an MVP or MVVM architecture, and a CalculatorState if you decide to put the state explictly in some object for persistence. There may be further infrastructure classes like a Program class for the application's entry point. But not a class called Calculator, this name makes only sense at the namespace level, but not at the class level.

This is not restricted to this specific example. A program or library consists always of different parts - so give those parts a name which distinguish them clearly from the program name and makes them distinguishable from other parts, then the problem won't occur.