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.

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

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.